W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2012

Re: [Graph] abstract syntax for dealing with multiple graphs

From: Ivan Herman <ivan@w3.org>
Date: Wed, 7 Mar 2012 14:36:47 +0100
Cc: RDF WG <public-rdf-wg@w3.org>
Message-Id: <32255089-833A-421A-A3E3-35422651716C@w3.org>
To: Antoine Zimmermann <antoine.zimmermann@emse.fr>

On Mar 7, 2012, at 14:27 , Antoine Zimmermann wrote:

> I'd like here to leave the conversation on semantics aside and see what we can do about the abstract syntax that we want to allow for dealing with multiple graphs.
> 
> There seems to be 3 categories of abstract syntaxes in what has been used as examples so far:
> 
> 1) use triples with a "graph-literal-like" syntax:
> 
> :g :r { :s :p :o }
> 
> or
> 
> :g :r ":s :p :o"^^:graph
> 
> *Pros:* it's an RDF Graph. No new data model is needed. One just need a datatype for graph-literals. The concrete syntax is like RDF.
> *Cons:* (most) current implementations do not recognised this.

They would not recognize the shorthand form, ie, { ... }. But any syntax we define will have a similar issue. This has the advantage, on the other hand, that the ":s :p :o"^^:graph form IS recognized by any Turtle parser

> *Issue:* is it really a literal? or a new construct? Are any relation :r allowed here? do we define a fixed set of relation that can be used with this syntax? What happens when graph literals are embedded in graph literals?
> *My opinion:* preferably no. This introduces a new concrete domain (RDF graphs) which is difficult to deal with (e.g., no standard cannonicalisation). We have no pragmatic experience with this.
> 

I would completely rule that out yet. If it is a literal, then what we have to do is to define its lexical space (and I would not mind if, today, we defined the lexical space sticking to turtle only, for example) and the value space being all set of RDF graphs, with equality being graph equivalence. I am sure it is not that simple but, at first glance, this does not look THAT bad...

Ivan

> 
> 2) Datasets, e.g.,
> 
> :g { :s :p :o . :a :b :c . }
> 
> *Pros:* datasets are already a standard data model, as part of the SPARQL rec. TriG would be a natural concrete syntax, and it's already supported by some implementation. "Normal" RDF graphs are immediately accessed via the graph "names".
> *Cons:* how to define the semantics of datasets? It's a new data model that would need to be introduced in the concepts of RDF.
> *Issue:* are literals / bnodes allowed as "graph names". Are default graphs allowed as in SPARQL?
> *My opinion:* yes we can. See the dataset proposal on the wiki.
> 
> 
> 3) N-Quads (or a quad-based syntax),
> 
> :s :p :o :g .
> :a :b :c :d .
> 
> *Pros:* straigforward extension of RDF (triples with a parameter). Nquads as an obvious concrete syntax. Already used and implemented in some tools.
> *Cons:* relationship with "normal" RDF graph less clear than with datasets.
> *Issue:* what is allowed in 4th position? Do "quad-graphs" replace RDF 1.0 graphs or is it a new, distinct data model for dealing with multiple graph?
> *My opinion:* yes as well, in addition to Datasets. In any case, datasets can be transformed isomorphically into quads and vice versa.
> 
> The difference is that datasets are sets of pairs, while quad-graphs are sets of quadruples. Each one has its own advantages. I would like that both are presented, and both a TriG-like syntax and a Quad-based syntax be standardised. NQuads could as well be a standard syntax for exchanging pure RDF graphs, by simply ommitting the fourth value.
> 
> 
> Best,
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 83 36
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Wednesday, 7 March 2012 13:36:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:47 GMT