Re: SOURCE : handling a graph read in twice at different times

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