Re: RDF Profiles in Link Values

Sean,

My €0.02: Ignore the titles, or take them just as a very broad hint.  
Load all files typed application/rdf+xml with potentially interesting  
hints, and inspect them to see if there is any data you want. The  
data is self-descriptive for a reason.

That's what schema-agnostic clients will do anyway.

Yes, profiles might make things a bit more efficient for schema- 
specific clients, but I wonder if it's worth the hassle. Unless I  
hear anyone say, "All these FOAF files are killing my DOAP crawler!",  
I will conclude that the proposal tries to solve a non-issue.

Richard


On 17 Nov 2006, at 14:20, 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,
>
> -- 
> Sean B. Palmer, http://inamidst.com/sbp/
>
>

Received on Friday, 17 November 2006 14:25:48 UTC