Hey Earle,
On 16/03/07, Earle Martin wrote:
Hola,
On 15/03/07, Tom Heath wrote:
One of the things that confuses this issue IMO is the Guides use of hash URIs, i.e. tagging #obj on to the end of the URI of a page about something, to make a URI of the thing itself. It's not a particularly pretty/ideal pattern to follow in an RDF world.
That was a very conscious decision on my part following the discussion on the "httpRange-14" issue within the W3C, which I'm sure you're familiar with. For those who aren't, the conclusion (which I believe postdated our implementation) can be found at http://lists.w3.org/Archives/Public/www-tag/2005Jun/0042.html .
Sure. Great that the OGs are ahead of the curve on this. The httpRange-14 resolution is starting to get traction and does provide a decent means to move forward.
...It can be summarised as "if your server responds with a 200 range code to a URI, it's an information resource; but anything within that resource with a fragment identifier is not".
If I've understood the theory correctly, then yes, this is largely true and fine if you simply have an RDF document at the URI (in a document that defines an ontology, for example), but is incorrect if the information resource is an HTML document (where a fragment identifier identifies a part of the document, i.e. an information resource). Therefore we probably shouldn't make that assumption, but instead say "we don't know what a hash URI identifies". Richard Cyganiak covers this quite nicely I think:
<snip>If TimBL says that hash URIs always represent concepts, and not part of documents, then he contradicts RFC 3986 and introduces an ambiguity that is just as bad as the original "URI crisis" which httpRange-14 was designed to solve.</snip> http://dowhatimean.net/2006/11/content-negotiation-with-hash-uris-long
Our current behavior is in accordance with this, and I don't wish to change it. Why do you > think it's not ideal?
Sure, I can understand that. My preference (and it is a preference) for doing it differently comes down to the "hash URIs vs slash URIs" debate. I prefer slash URIs as I believe they make a clearer distinction between a thing and a document about a thing (and 303 redirects help avoid any ambiguity). They also send a stronger message about a URI of a thing being independent of any one particular document. For example, even though it makes no difference at the machine level, as a human being using http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj to identify the pub in a different document would still niggle me a bit. It just seems the wrong way around; surely the pub is the primary object, and any particular description of it is secondary? Like I say, this is a preference, and I'm certainly not having a go at you about it, it's just my general opinion on hash URIs :)
Incidentally, "obj" itself was something I made up after failing to find a better alternative to the word "thing", which I have a strong dislike for. I'm happy for better suggestions.
I think it's fine, it follows the Ronseal approach. Would be interested in hearing you reasons for dislike of "thing", although you're welcome to save that for a face to face discussion over a beer sometime if you'd prefer.
Obviously it's grown up organically and we're dependent on many other modules,
Sorry? I don't follow... The RDF is completely independent of anything; it was hand-composed. Unless you're referring to schemata (yay Greek!) that we rely on as modules, rather than Perl modules?
OK, that's interesting, I hadn't realised that. What I was really getting at is that (as I understand it) the OG software relies on Perl modules for generic Wiki functionality (of course I may be totally wide of the mark here, having never really delved around under the hood). If that is the case then our ability to redfine the addressing scheme for OpenGuides and create "pretty URIs" may be limited, as the modules define the URI syntax. Please clarify things for me if I'm wrong about this.
ideally we'd use a URI pattern that went something like: http://wherever.openguides.org/thing-name-locale/ to identify things in the guide, with pages of information about the things being at http://wherever.openguides.org/thing-name-locale/about
Ideally for human readers? It's all much of a muchness to the robots... as long as the fragment identifiers are kept, I'm happy, though.
Yes, ideally for human readers. Sure, the robots don't care either way, but URIs will inevitably end up in human hands, so making them easily digestible is desirable IMO.
Just so I follow you, are you wedded to the fragment identifiers themselves, or simply the distinction between the "object/thing" and the "document about the object/thing"?
Replace the /html you'll likely get in the URL with /rdf for an RDF version. I'm guessing this isn't really very feasible for the OpenGuides right now, although liberal use of Apache Rewrite rules might get us a lot of the way.
A couple of years back I experimented with a pure-Perl method of doing better URLs (no rewrites required), which ended up with something like that. Nothing ever came of it, but I wouldn't mind resuscitating the idea.
Cool. Sounds good to me :)
First off, one thing that would help would be to make a link between the <uriofpageaboutathing> and the <uriofthingitself>. This is lacking at the moment as far as I can tell, hence the lack of links from http://tinyurl.com/ynwxze to http://tinyurl.com/28pt4k. The foaf:primaryTopic property should be sufficient for this.
Good call. I could have sworn we did this already, but obviously not. It's a trivial change.
Great. I only checked the london.randomness guide btw, so others may differ but I assumed it represented the state of the art as it runs 0.58 (the latest?).
The next job is to fix some links in the RDF describing the thing. For example, http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj is apparently foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#Rotherhithe Now, this may not be incorrect, but there is very little info about Rotherhithe at that URI. Instead we should be saying ... foaf:based_near http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf
(I think you mean http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob... ! Since it's not based near an RDF document.)
Indeed. Thanks, my mistake.
But you could say that; alternatively, the wn:Neighborhood item "Rotherhithe" could be given an rdfs:isDefinedBy rdf:resource="http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#ob.... Your version is more compact, but doesn't specify that Rotherhithe is a wn:Neighborhood, which is an explicit definition that I quite like.
The more semantics the better I reckon, so saying that it's a Neighbo(u)rhood would be great. Something like:
<uriForRotherhithe> foaf:isPrimaryTopicOf <documentAboutRotherhithe> <uriForRotherhithe> rdf:type wn:Neighborhood
might be a nice way to express these things (would need to double check this before commiting it to code); I'm not totally sure of the semantics of rdfs:isDefinedBy, so not sure if we can make such a strong claim as <uriForRotherhithe> rdfs:isDefinedBy <documentAboutRotherhithe> (hence foaf:isPrimaryTopicOf).
That RDF file should then ideally contain lat/lon data about Rotherhithe, and links to all the things located in that locale.
Sounds good.
Great :)
The same issue affects "bob"; rather than just linking to <somenodename;format=rdf#bob>, it would be great to identify Bob with a URI, http://wherever.openguides.org/contributors/bob/ perhaps;
See above; it would have to be something more like http://wherever.openguides.org/contributors#bob
Not necessarily. If http://wherever.openguides.org/contributors/bob/ returned a HTTP303 response and a "Location: http://wherever.openguides.org/contributors/bob/about" header, (where http://wherever.openguides.org/contributors/bob/about was a document describing Bob) then we'd be doing the right thing aswell. The # isn't essential.
Thanks for the input!
Any time :) Thanks to everyone on this list who has actually created and hosted the OG software so guys like us at the OGMK can come along and actually use it.
PS. If anyone else on this list is really into this stuff, then the Linking Open Data project http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData is doing some cool stuff in this space. OpenGuides is already listed under datasets.
I know you saw http://dev.openguides.org/wiki/RDF%20Workshop before, but there's a little bit of stuff I dumped on it towards the end relatively recently that may be of interest. The above link would be worth adding.
Cool. Will have a look. Agreed that the link would be worth adding. Have forgotten my Trac password, so will get around to requesting a new one at some point ;)
Cheers,
Tom.