- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Mon, 6 Jun 2005 10:19:54 +0200
- To: public-rdf-dawg-comments@w3.org
Good morning, A post over on redland-dev [1] brought my attention to the current postponed status of the question of accessing Collections/containers (even though there appears to be some coverage for Collections in the draft..?). As and when the issue returns from postponement, I'd like the following to be taken into consideration. It's the containers side this post concerns. I can totally understand avoiding putting anything in place to cover the user-expected semantics of containers, as opposed to what RDF Semantics covers. So preservation of the order of an rdf:Seq probably doesn't have a place in the spec. But to retain some utility, the current behaviour of Redland seems to work. Example - an RSS feed contains: <channel rdf:about="http://www.xml.com/xml/news.rss"> <title>XML.com</title> <items> <rdf:Seq> <rdf:li resource="http://xml.com/pub/2000/08/09/xslt/xslt.html" /> ... ... ... <item rdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html"> <title>Processing Inclusions with XSLT</title> ... Given a query: SELECT ?name, ?title, ?x, ?y WHERE { ?channel rdf:type rss:channel . ?channel rss:title ?name . ?channel rss:items ?x . ?x ?y ?item . ?item rdf:type rss:item . ?item rss:title ?title . } This will return: ?name = "XML.com" ? title = "Processing Inclusions with XSLT" ?x is bound a bnode, y is bound to a resource of the form rdf:_9. This kind of access provides the necessary connectivity, and I'd suggest would do for at least a provisional approach for the spec, with the proviso that the actual binding of ?y remains unspecified. I don't know if there a precedent for deprecation by proxy, but it wouldn't seem unreasonable to me to include a note saying "RDF implementors intending to use SPARQL should avoid using containers in their designs". Cheers, Danny. [1] http://lists.gnomehack.com/pipermail/redland-dev/2005-June/000961.html -- http://dannyayers.com
Received on Monday, 6 June 2005 08:20:00 UTC