Warning:
This wiki has been archived and is now read-only.

TF-Graphs-Designs

From RDF Working Group Wiki
Jump to: navigation, search


This page lists designs which can be used to address the Highlighted Uses Cases. It started from Sandro's "three solutions" email.

1 TriG/state

One solution is to use TriG (or an equivalent syntax) and say the relation between each label and its associated RDF Graph is that the Graph represents the state of the Web Resource identified by that label, using the normal Web notion of IRIs identifying resources. This relation is what TimBL's cwm implements as log:semantics; Sandro has proposed a better name for the relation is rdf:graphState.

This is a common way to use TriG or SPARQL Named Graphs. Each time the client fetches some RDF content G from a URL U, it stores G with the label U in its store.

The truth of a TriG/state document depends on time, since the state of Web resources depends on time. (The state may also be seen as depending on other contextual factors, more than just time. More on this later.)

From message of Sandro, 4 Jan 2012:

 http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0021.html

1.1 Summary of semantics of the name-graph relationship

The graph name is an IRI. This IRI represents a graph container. A GET operation on the IRI fetches the triples of this graph container.

1.2 Use-case examples deploying this solution

1.2.1 UC: access to crawler data, not time dependent

@@ ref needed, presented by cygri at 21 Dec meeting

Several systems want to use the data gathered by one RDF crawler. They don't need simultaneous access to older versions of the data.

Solution: use TriG or N-Quads with the fourth column (graph label) being the URL the content was fetched from.

 <http://example.org> 
   { ... triples recently fetched from there }

1.2.2 UC: access to crawler data, time dependent

Several systems want to use the data gathered by one RDF crawler. They need simultaneous access to older versions of the data.

Solution: use TriG or N-Quads with the fourth column being some identifier created at the time the retrieval was done. Then, some other data connects that identifier with the URL the content was fetched from.

 <http://crawler.example.org/r8571> 
   { ... triples fetched in retrieval 8671 }
       
 { 
   <http://crawler.example.org/r8571> 
     eg:source <http://example.org>;
     eg:date "2011-01-04T00:03:11"^^xs:dateTime
 }

1.2.3 UC: endorsing triples

A system wants to convey to another system in RDF that some person agrees with or disagrees with certain RDF triples.

Solution: rather than endorsing an RDF Graph, in this design one endorses a Graph Container on the condition that it never changes. This semantic condition is expressed through typing the graph IRI.


 { eg:sandro eg:endorses <g1>.
   <g1> a rdf:StaticGraphContainer.
 }
           
 <g1> { ... the triples I'm endorsing ... }

ISSUE: vocabulary for graph types

  • which vocabulary terms are needed?
  • limitative or non-limitative set of predefined terms?
  • suggest best practice for vocab terms
  • namespace for the vocab terms: rdf: / rdfs: / something else?

ISSUE: impact on semantics

  • should we have this vocabulary purely as a convention without touching the semantics?

2 TriG/equals

Another solution is to use TriG (or an equivalent syntax) and say the relation between each label and its associated RDF Graph is that the label refers to the Graph, in the normal RDF sense in which IRIs refer to things.

2.1 @@ applied to use cases

3 Graph Objects

Another solution is to use a language which allows RDF graphs to be written in the object position of RDF triples.

This solution subsumes TriG/state and Trig/equals by giving each of those an explicit predicate URI.

So the TriG/state document:

eg:g1 { eg:s1 eg:p1 eg:o1. }

and the TriG/equals document:

eg:g2 { eg:s2 eg:p2 eg:o2. }

could be merged into one document like:

eg:g1 rdf:graphState { eg:s1 eg:p1 eg:o1. }
eg:g2 rdf:isGSnap { eg:s2 eg:p2 eg:o2. }

3.1 @@ applied to use cases

4 Graph Datatypes

Similar to Graph Objects, but more clumsy, and without a clear way to share blank nodes:

eg:g2 owl:sameAs "eg:s2 eg:p2 eg:o2"^^rdf:turtle.

4.1 @@ applied to use cases

5 Relation Flag

With this approach, a flag is added to TriG indicating which relation is intended between the resource named by the label and the associated RDF Graph.

For example, to get TriG/state semantics:

{ <> rdf:graphLabelRelation rdf:graphState. }
eg:g { eg:s eg:p eg:o. }

or, to get TriG/equals semantics:

{ <> rdf:graphLabelRelation owl:sameAs. }
eg:g { eg:s eg:p eg:o. }

If the flag is absent from the document, and not provided out of band, the the relation is unknown. Happily, this is current state of affairs with TriG, so we have backward compatibility.

5.1 @@ applied to use cases

6 Typed Labels

See Graphs Design 6.1 for a more detailed proposal.

With this approach, the relationship between the resource IRI used as the label and the RDF Graph is implied by an rdf:type declaration for the resources. There can be different relationships in the same TriG document. Merging TriG documents to yiled another TriG is possible.

{ :ga rdf:type rdf:Graph .

  :gb rdf:type rdf:StaticGraphContainer .

  <tag:event:1234> rdf:type rdf:Observation ;
      :timestamp "2012-02-08T15:56:50Z"^^xsd:dateTime ;
      :resource <http://example/weather> .
}

:ga { :s1 :p1 :o1 . 
      :s2 :p2 :o2 .
    }

:gb { :x :q 123 ; :q 567 . } 

<tag:event:1234> { :s9 :p9 "good" . } 

rdf:Graph implies a "same as" relationship,

rdf:StaticGraphContainer is an unchanging web resource and implies it's the same triples on every HTTP GET access.

rdf:Observation means the value obtained by GET on a resource at a point in time and that the resource might be changing over time.

6.1 @@ applied to use cases