[OGDev] What are people working on?

Fri Mar 16 13:29:53 GMT 2007

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#obj
> ! 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.