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#o…
! 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#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).
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.