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

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"

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.

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?

	Andy

Received on Wednesday, 7 March 2012 14:03:54 UTC