Hi Tom, sorry for the slow reply, I've been busy.
On 16/03/07, Tom Heath tom.heath@gmail.com wrote:
...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".
Okay, I guess that's a fair call.
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
Hrm. Interesting discussion, thanks for the pointer. I certainly don't agree with that John Black fellow about "claims". RFC 3986 confuses me somewhat, as it says "Fragment identifiers... [allow] an author to specifically identify aspects of an existing resource..." This seems to imply that a fragment only refers to an aspect of a resource, which sounds at odds with fragmentInXML-28 (http://www.w3.org/2001/tag/issues.html#fragmentInXML-28), which says: "In general, the fragment part of a URI may be used to refer to abstractions as well as syntactic fragments of a representation". Still, it's not really our place to try and resolve this issue here; a perfectly acceptable workaround exists in the form of the 303 redirect proposed by the resolution to httpRange-14. So that's fine, I'm happy.
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.
Yeah, sure; to a human a pile of line-noise (.?&=%bleah) isn't too clear. Would you prefer example.com/guide/Foo_Bar/rdf or example.com/guide/rdf/Foo_Bar? Also, since those would be the 303 redirects, what would they redirect to?
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?
Right. I'm sure we can hash something better out.
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.
Aw, no, I just think it sounds kind of weak. I think maybe "a strong aversion" was a little strong, it's more of a niggling dislike. :)
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.
Right. Well, at present the CGI interface defines the URI syntax, but we control the code, so the format of the URIs is entirely up to us. What can be thought of can be coded.
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"?
Definitely the latter.
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).
I'll look into it.
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.
Yep. That's great.
Cheers,
Earle.
Hey Earle
Hi Tom, sorry for the slow reply, I've been busy.
No worries. Know the feeling :)
Sounds like we're pretty much in agreement about most things, so I'll just reply to the other stuff...
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.
Yeah, sure; to a human a pile of line-noise (.?&=%bleah) isn't too clear. Would you prefer example.com/guide/Foo_Bar/rdf or example.com/guide/rdf/Foo_Bar? Also, since those would be the 303 redirects, what would they redirect to?
I have a reasonable preference for the <example.com/guide/Foo_Bar/rdf> pattern, as it allows to substitute /rdf with other "extensions" for other serialisations, e.g. /html, /n3, /txt, whilst also being conceptually similar to regular .html or .rdf file extensions. Plus it puts the object first and the serialisation second, which just kinda seems right :)
In terms of the redirects, the URI http://example.com/guide/Foo_Bar/ identifies this object/thing, and so redirects would be served on this URI, redirecting with 303s to e.g. http://example.com/guide/Foo_Bar/rdf or http://example.com/guide/Foo_Bar/html. Ideally content negotiation on the object URI would redirect the user-agent to the relevant serialisation. All links within an OpenGuide would then be made to the object URI I guess, rather than to either of the URIs that represent HTML or RDF documents describing the object that is identified by the object URI (and breathe...), though haven't given this much thought yet.
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?
Right. I'm sure we can hash something better out.
Cool.
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.
Right. Well, at present the CGI interface defines the URI syntax, but we control the code, so the format of the URIs is entirely up to us. What can be thought of can be coded.
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"?
Definitely the latter.
Great.
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.
Yep. That's great.
Fantastic, sounds like we're all singing from the same hymn sheet. I'll try and do that "this would be an ideal RDF output for an OpenGuide entry" mockup sometime soon, as previously promised, and assuming it's still relevant. Don't wanna duplicate effort with anything you might work on though Earle, so shout if this would be the case.
Cheers,
Tom.
On Fri, Mar 30, 2007 at 03:07:18PM +0100, Tom Heath wrote:
Fantastic, sounds like we're all singing from the same hymn sheet.
I think you [1] probably are, but I'm aware Dom's not here to comment at the moment and AIUI everything needs to be approved by him before it'll go into a release.
I'm probably making a fool of myself here: you're all probably aware of this and know much better than me how things are done, but I'd be waring of spending loads of time programming in a direction Dom hasn't indicated will get released.
s
[1] IANAP :(
On Fri 30 Mar 2007, Stephen Gower socks-openguides.org@earth.li wrote:
I think you [1] probably are, but I'm aware Dom's not here to comment at the moment and AIUI everything needs to be approved by him before it'll go into a release.
To clarify a little, from my understanding, additions to RDF aren't likely to be controversial, since RDF output is something of a moving target anyway, and it's just another output format so that layer can always be rewritten in the future - hence, RDF stuff that's asked for by an actual consumer such as Tom[0] is (I think) likely to go in, for the time being at least. (The lack of consensus among RDF consumers does, I think, mean that OpenGuides RDF output certainly shouldn't be regarded as anything approaching stable.)
[0] So yes, Tom, your mockup of ideal output would definitely be useful.
On the other hand, major changes such as a complete overhaul of the URL scheme probably shouldn't be relied on until there's more consensus - and I don't see consensus yet.
Kake
We were talking about RDF on #openguides today, and perigrin pointed out that the node RDF for a node that's a category really should have a link to the RDF version of the list of all nodes in that category.
In order to facilitate this, and other RDF improvements, I've moved the stuff that generates a node's RDF from RDF.pm to node_rdf.tt; this has just been committed to svn.
I hope this doesn't upset the plans of anyone else who was working on RDF output; it shouldn't make things harder for you, rather, it should make things a lot easier. If it doesn't, let me know, and I'll help you sort it out.
A side bonus of this is that I also changed our home-grown and rather inadequate character-escaping to use the encode_entities_numeric stuff in HTML::Entities, which does it properly. With any luck we should now be free from invalid XML, in the node view at least. It needs to be done for the index view as well though.
Re perigrin's request, I added something that looks about right to the Vegan Guide to Oxford:
<rdfs:seeAlso rdf:resource="http://the.earth.li/~kake/cgi-bin/openguides/vegan-oxford.cgi?action=index;i..." />
But Disco isn't picking it up properly for some reason. Could the RDF experts have a look at
http://the.earth.li/~kake/cgi-bin/openguides/vegan-oxford.cgi?id=Category_Re...
and see if it looks right to you? Also if you could take a look at the RDF on the other pages on that site, and see if I managed to break anything while switching to the new node_rdf.tt? All the tests pass, but I'm aware we don't have tests for everything.
Kake
On 04/04/07, Kake L Pugh kake@earth.li wrote:
In order to facilitate this, and other RDF improvements, I've moved the stuff that generates a node's RDF from RDF.pm to node_rdf.tt; this has just been committed to svn.
I meant to reply to this earlier - that's a real help. Thank you very much.
Re perigrin's request, I added something that looks about right to the Vegan Guide to Oxford: [...] Could the RDF experts have a look at http://the.earth.li/~kake/cgi-bin/openguides/vegan-oxford.cgi?id=Category_Re...
and see if it looks right to you?
Hmm, seems fine. The validator OKs it: http://www.w3.org/RDF/Validator/ARPServlet?URI=http%3A%2F%2Fthe.earth.li%2F%...
Also if you could take a look at the RDF on the other pages on that site, and see if I managed to break anything while switching to the new node_rdf.tt? All the tests pass, but I'm aware we don't have tests for everything.
Looks good so far.
On Fri, Mar 30, 2007 at 04:00:34PM +0100, Kake L Pugh wrote:
On Fri 30 Mar 2007, Stephen Gower socks-openguides.org@earth.li wrote:
I think you [1] probably are, but I'm aware Dom's not here to comment at the moment and AIUI everything needs to be approved by him before it'll go into a release.
To clarify a little, from my understanding, additions to RDF aren't likely to be controversial, since RDF output is something of a moving target anyway, and it's just another output format so that layer can always be rewritten in the future - hence, RDF stuff that's asked for by an actual consumer such as Tom[0] is (I think) likely to go in, for the time being at least. (The lack of consensus among RDF consumers does, I think, mean that OpenGuides RDF output certainly shouldn't be regarded as anything approaching stable.)
I'm happy for those with an interest in RDF to take the lead on RDF support in OpenGuides so no particular comments about this :)
Cheers,
Dominic.
openguides-dev@lists.openguides.org
-
Dominic Hargreaves -
Earle Martin -
Kake L Pugh -
Stephen Gower -
Tom Heath