RDF Profiles in Link Values

This kind of idiom is starting to gain traction:

 FOAF: <link rel="meta" type="application/rdf+xml" title="FOAF" href="[url]" />
 SIOC: <link rel="meta" type="application/rdf+xml" title="SIOC" href="[url]" />
 DOAP: <link rel="meta" type="application/rdf+xml" title="DOAP" href="[url]" />
  - http://ping.semanticweb.org/

But as Dan Connolly recently noted on #swig to Uldis Bojars, this
idiom is architecturally unsound:

http://chatlogs.planetrdf.com/swig/2006-11-13.html#T18-28-36

There are three reasons for this:

 * The title is not explanatory, as an HTML title should be.
 * Because it's a free-for-all namespace, collisions are possible.
 * The heuristic may fail even on more explanatory titles.

On the other hand, there is the benefit of it being really easy to
write. I have a suggestion of an alternative which is just as easy to
write, but which is also architecturally sound:

   <link rel="meta nn.ont.foaf" type="application/rdf+xml" href="foaf.rdf" />

Where nn.ont.foaf is a reversed domain name, a la Java package names.
Somebody could register a very short domain such as ont.cc, and open
it up to some kind of community maintenance, to get the process
started and get consensus on names.

So, what kind of practical problems does this actually fix? Well, the
title="DOAP" thing is, as noted, bad because as an HTML title it is
not very explanatory. DanC suggested searching instead for substrings
in a title:

18:30:22 <DanC> hmm... do the consumers rely on the title being "DOAP"
exactly? if would be cool if they allowed title="some DOAP data about
the foaf explorer"
18:30:54 <DanC> i.e. the autodiscovery spec could use the presense of
DOAP as a substring in the title to be a hint. That's fairly
reasonable.
- SWIG IRC Channel, 2006-11-13

But if you look at his example, you can see the problems that
heuristics face here. If you have the following titles:

   title="Some DOAP data about the FOAF project."
   title="The FOAF project's DOAP data."

Does the autodiscovery agent take this as being DOAP data or FOAF
data? It's ambiguous. This is because this hinting mechanism is a
hack: @title was written for human readable titles, not for
autodiscovery hints.

Uldis Bojars asked me on IRC what the consequence of this is. Well,
obviously, if a tool is looking for autodiscovery hints then it's
likely passing them off to some dispatch mechanism. For example, you
might have a different display module for DOAP than for FOAF. You
might have a SPARQL query that only looks for DOAP properties if the
title is "DOAP". You might even pass by data altogether if it doesn't
use an ontology you know.

It'd be nice if authors of autodiscovery tools would chime in and note
what they use autodiscovery RDF profile hints for, and whether the new
proposed mechanism would be both a significant boon to them in light
of the above, and be significantly difficult to migrate to or not.

Remember, the new approach is easy to write:

   title="DOAP" -> 12 characters
   xx.ont.doap -> 11 characters

And if there were a simple short named community site for reverse
domain names it would be easy to remember the codes to use (it's a
shame there's no .sw country-code domain extension, because sw.ont
would be rather nice to have). If someone already has a decent domain
name to use, please do mention it.

There is also some precedence for this approach. Dublin Core have
recommended dotted link values for years:

 <link rel="DC.relation" href="http://www.example.org/" />
  - http://dublincore.org/documents/dcq-html/

And, in XHTML 1.0 at least, it's clear that dotted values are fine:

 <!ENTITY % LinkTypes "CDATA">
 <!-- space-separated list of link types -->
  - http://www.w3.org/TR/xhtml1/dtds#dtdentry_xhtml1-strict.dtd_LinkTypes

Though of course Dublin Core just squats "dc"; it'd be nice if they
used org.dcmi.author and the like instead. That race is probably over
now, but the title="DOAP" idiom hasn't been around for all that long,
so if we want to fix it, we'd better do it now.

See also http://www.w3.org/2001/tag/issues#standardizedFieldValues-51

Cheers,

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Friday, 17 November 2006 13:21:33 UTC