- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 01 Jun 2005 15:51:19 +0100
- To: Dan Connolly <connolly@w3.org>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Dan Connolly wrote: <snip/> > > Also, Andy, can you take TimBL's comment > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Nov/0020.html > > and extract a test case that shows how the difference > between the 12 Oct design and what TimBL is asking for? In the Oct 12 design, expresses in current language, the default graph (Tim's default KB) is the RDF merge of the named graphs. Tim made two points: 1/ There are many ways to create graphs - merge is just one of them. His example 0 show one that is the OWL closure of the merge. This seems quite timely again with possible rules work in the air. 2/ That the default to believing (Tim's word) all RDF and the merge of the RDF is dangerous. The example 2 is FOAF based. Example 0: G1.ttl: :mary foaf:phone "1234" . G2.ttl :mary owl:sameAs :maryJ . then SELECT ?phone WHERE { :maryJ foaf:phone ?phone } gives :maryJ has phone "1234" yet no graph made this claim. G2 can injected by a third party. ------------------------------ Suppose we have two graphs that have been got through crawling. One happens to be out of date but that's the nature of FOAF: Named graph <G1> _:x foaf:name "Alice" . _:x foaf:mbox <mailto:alice@example.org> . _:x diet:preference "Vegetarian" . Named graph <G2> _:y foaf:name "Alice" . _:y foaf:mbox <mailto:alice@example.org> . _:y diet:preference "Vegan" . Let's try checking dietary preferences: ASK { [ foaf:name "Alice" ; diet:preference "Vegan" ] } => (Oct 12 design) Yes => (Tim asks for) No Tim as asking that this return nothing unless the publisher has decided to put that information in the default graph. The publisher is to be made responsible for claims in the default graph just like a plain graph and HTTP GET. Andy <snip/>
Received on Wednesday, 1 June 2005 14:54:52 UTC