RDF improvements (was: What are people working on?) - OpenGuides-Dev

29 Mar 2007

Hi Tom, sorry for the slow reply, I've been busy.

On 16/03/07, Tom Heath &lt;tom.heath(a)gmail.com&gt; 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#obj">.
 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.

-- 
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/