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.