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

On Mar 7, 2012, at 15:03 , Andy Seaborne wrote:

> 
> 
> On 07/03/12 13:36, Ivan Herman wrote:
>> 
>> On Mar 7, 2012, at 14:27 , Antoine Zimmermann wrote:
> 
> Nice summary of possibilities.
> 
>> 
>>> 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...
> 
> ??
> 
> "would" => "would not"

:-) Sorry about the confusion


> 
> based on the sense of the rest of the paragraph and the "this does not look THAT bad..."
> 
>> 
>> Ivan
> 
> Two things that need considering:
> 1/ matching
> 2/ large literals
> 
> 1/ => matching becomes difficult to explain to app writers as the size of the graph grows.
> 
> c.f. XMLLiterals and canonicalised.  Not a million miles away ...
> 
> People use XMLLiterals for GML data ...
> ... and wonder why either they get data rejected (by a picky parser) or
> no query matches (pass-through parser) because the input GML isn't canonical.

I am not sure the situation is the same. XML Canonicalization is used because that is the only way two XML files can be compared and declared to be equal or not. 

But the RDF Semantics already defines when two Graphs are considered identical. Ie, if the value space is defined to be RDF graphs, then equality comes naturally.

I agree that the practical implementation of the equivalence is not easy, though. But I would expect that a number of systems already do that.

> 
> 2/ => General observation: managing large blobs for hidden structure can limit their usefulness.
> 
> So "turtle"^^graph is OK for transmission but graph-datatype-literals (GDLs) may need specialised handling.  An obvious user expectation is to use SPARQL on them ... extend GRAPH to work on such literals?
> 

I guess that depends on our beloved term 'semantics':-)

My initial answer would be no. They are literals. Of course, if there is a URI that associated with that literal, and association is really 'naming', then that URI could be used in a FROM clause. But there is nothing new there.

I agree that large graphs may become unmanageable this way...

I am not arguing that we MUST take them on board. But I am not sure we should dismiss them right away.

Ivan


> 	Andy
> 


----
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