- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Sun, 16 Jan 2005 16:42:59 +0000
- To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Steve Harris wrote: > On Sat, Jan 15, 2005 at 08:37:57 +0000, Andy Seaborne wrote: > >>Steve Harris wrote: >> >>>On Fri, Jan 14, 2005 at 03:38:01PM -0600, Dan Connolly wrote: >>> >>> >>>>If you have a novel position on an issue, not represented by one of the >>>>options or even close, mail the wg with the issue name in the subject >>>>and I'll try to add it. >>> >>> >>>For the SOURCE issue I would like what Alberto and I do currently to be >>>considered, as in >>>http://www.w3.org/2001/sw/DataAccess/tests/#source-query-001 2 3 & 5 >>>AFAIK it is the only solution that was arrived at independently by more >>>than one working group member, and it represents our development and >>>support experience. >>> >>>The key feature is that the URI used to identify the triples (ie. bound by >>>the SOURCE keyword) is not neccesarily the URI that was resolve to >>>retreive the grpah, that may be got by following some predicate from the >>>SOURCE URI to the actual URI resolved (dc:sounrce in the testcases). >>> >>>This allows more that one version of a graph identified by the same URI to >>>be present in the store at one time, without confusion. >>> >>>- Steve >>> >> >>This is possible with the mechanism currently in the document. >> >>rq23 does not prescribe that the URI that names the graph is the URI it is >>read from and a predicate can connect the two - it's your choice Use of >>FROM or GRAPH is optional - the RDF dataset can be set externally but I >>have used them here so that the queries can go in a manifest. > > > OK, that sounds good. > > >>==== Query 1 : >> >>PREFIX foaf: <http://xmlns.com/foaf/0.1/> >>PREFIX dc: <http://purl.org/dc/elements/1.1/> >> >>SELECT DISTINCT ?name ?source ?date >> >># explicitly name the graphs just for clarity - note internal names >># Manifest format can't express this externally. >> >>FROM <urn:x-local:details> # The place when provenance info is kept >>GRAPH <urn:x-local:graph1> # Allocated when aliceFoaf read in >>GRAPH <urn:x-local:graph2> # Allocated when bobFoaf read in >> >>WHERE SOURCE ?snode (?person foaf:name ?name) >> (?snode dc:source ?source) >> (?snode dc:date ?date) >> >>and I get: >> >>---------------------------------------------------------------------- >>| name | source | date | >>====================================================================== >>| "Alice" | <http://example.org/foaf/graph> | "2005-01-10"^^xsd:date | >>| "BOB" | <http://example.org/foaf/graph> | "2005-01-10"^^xsd:date | >>| "Bob" | <http://example.org/foaf/graph> | "2004-12-06"^^xsd:date | >>| "Alice" | <http://example.org/foaf/graph> | "2004-12-06"^^xsd:date | >>---------------------------------------------------------------------- > > > Great, but whats the purpose of the FROM and GRAPH keywords here? Are they > to illustrate something I'm missing, or are they neccesary? Illustrating. Quoting from earlier: "Use of FROM or GRAPH is optional" My command line apps can't construct arbitrary RDF datasets from command line arguments yet. The manifest form can't describe them either. They can be specified in queries themselves. Putting then in was just to make the point and avoided writing a (small) custom program when the computer could already do it. > > >>==== Query 2 : >>PREFIX foaf: <http://xmlns.com/foaf/0.1/> >>PREFIX dc: <http://purl.org/dc/elements/1.1/> >> >>SELECT DISTINCT ?name ?source >> >>FROM <urn:x-local:details> >>GRAPH <urn:x-local:graph1> >>GRAPH <urn:x-local:graph2> >> >>WHERE SOURCE ?snode (?person foaf:name ?name) >> (?snode dc:source ?source) >> (?snode dc:date ?date) >> >>--------------------------------------------- >>| name | source | >>============================================= >>| "BOB" | <http://example.org/foaf/graph> | >>| "Alice" | <http://example.org/foaf/graph> | >>| "Bob" | <http://example.org/foaf/graph> | >>--------------------------------------------- Section 9.4 tries to explain this: http://www.w3.org/2001/sw/DataAccess/rq23/#sourcePlainGraph Suggestions for improvement? > > > Ditto. > > Also, if you read in a graph that has: > > <owl:Ontology rdf:about=""> > ... > </owl:Ontology> > > Does the ... get assertad with urn:x-local:foo, or the resolved URI as its > subject? The URI where the graph was read from - the external one - the http:// in the above. rdf:about="" is just shorthand and the relative URI resolution rules apply before local handling. An alternative modelling would be to have internal URIs to represent the event of reading the remote graph: <urn:x-local:graph1> :read "2005-01-16T03:8:03Z" ; :readFrom <http://example.org/foaf/graph> ; :size 23563 ; :processingApplied :rdfsRuleSet ; :cause <dailyUpdate> . (the test case is a slight cheat - it isn't clear what the dc:date refers to but it is an "event of interest", but you can't have another date now without confusion). ---- Keywords: The use of the word "SOURCE" is a bit weak. GRAPH would have been clearer and in a clearing out of the grammar, maybe using GRAPH for SOURCE (as GRAPH is a valuable keyword). FROM is SQL heritage back from rdfdb has: """ select [variable1, variable2, ... ... ] from {database} """ So: s/GRAPH/USE/ s/SOURCE/GRAPH/ any suggestions for specifying the unnamed graph (currently FROM) and named graphs (currently GRAPH) would be very welcome. I'd also like the FROM/USE (current FROM/GRAPH) to come before the SELECT. With PREFIX etc first, it seems more natural to me to have all setup first. > > - Steve > Andy
Received on Sunday, 16 January 2005 16:43:35 UTC