Re: RDF Profiles in Link Values

Sean,

This is _very_ interesting and timely. As Dan C among others knows, I'm 
working on a draft charter for a new W3C group that will, among other 
things, tackle this very issue. The DOAP use case is interesting. We're 
coming at it from wanting to know whether "if I follow this link to a 
bunch of RDF will there be anything about whether it's mobileOK or not" 
with other use cases around child protection, trustmarks etc.

The charter isn't finalised yet, let alone started its work, but your 
comments about some sort of repository that, in as few characters as 
possible, says "this is about mobileOK" is something I've had in the 
back of my mind for a while.

Cheers

Phil.


Sean B. Palmer wrote:
> 
> 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,
>

Received on Friday, 17 November 2006 17:08:14 UTC