Re: some GRAPHS strawpolls for today (agenda?)

Le 25/04/2012 16:08, Sandro Hawke a écrit :
> If we're going to talk about graphs today, maybe we can do it in a
> series of decisions.   There's not enough notice to make these binding,
> of course, but maybe we can get a sense of how close we are to
> consensus.
> If we can't even get consensus on a few of these, these I think we
> should stop working on graph semantics in this WG.  I hope we're very
> close to consensus on all of these, except maybe the last, which I could
> see continuing as an open issue well into CR.
> I've erred on the side of brevity here.
>       -- Sandro
> ====================================
> 1. The default graph is asserted
>    "{<a>  <b>  <c>}" entails turtle("<a>  <b>  <c>")

The notion of entailment is well defined and very standard notion in 
logics (any logics). It is a relationship between a theory in a logic 
and another theory in the same logic.

Here, it is used to relate a theory in a logic of multiple graphs (RDF 
Dataset, serialised as TriG) to a theory in a logic of a single set of 
triples (RDF, serialised in Turtle).

To say that an RDF Dataset entails an RDF Graph is like saying that an 
RDF Graph entails an XML tree.

It would be possible to define a mapping from RDF Graph to dataset, 
saying that an RDF Graph corresponds to an RDF Dataset which only 
contain that graph in the default graph, but then the entailment does 
not even need to be agreed upon as it would be true by definition.

> 2. Named graphs are not asserted
>    "<u>  {<a>  <b>  <c>}" does not entail turtle("<a>  <b>  <c>")

Same remark. If the mapping that I mentioned above is used, then I agree 
with this (it is in agreement with the dataset semantics of [1]).

> 3. Named graphs are opaque
>    "<u>  {<a>  <b>  <c>}"  does not entail "<u>  {<a>  <b>  _:x}"

Hmm, I prefer that it *does* entail. Basically, I read this as follows:

"<u> says that <a> is in relation with <c> by property <b>". From this I 
can infer that "<u> says that <a> is in relation with something by 
property <b>", which what the right hand side of the entailment 
expresses. I thought that this was pretty much consensual and it is what 
I defined in my proposal.

But again, this could be chosen by the maintainer of the dataset and 
indicated with a meta-statement in the dataset file.

> 4. Graph labels denote just like in RDF
>    "{<u1>  owl:sameAs<u2>}<u1>  {<a>  <b>  <c>}"
>    owl-entails
>    "<u2>  {<a>  <b>  <c>}"

While I find item 3. to be too liberal, I find this to be too 
restrictive. Remember there are existing practices, not so uncommon, 
where the graph label is the URI of the primary topic of the graph 
(could be denoting a person, a troll, a cocktail). If there are two 
distinct graphs that have the same primary topic (e.g., two descriptions 
of Barrack Obama, one from the democrats, one from the republicans).

In order to accomodate all use cases, an indication like 
"@graph-label-denote-graphs" could be added.

> 5. Blank nodes labels have file scope
>     See SPARQL queries in
>     or Skolemization example in

I don't like this much but I could live with it as bnodes can always be 
renamed to make sure they only appear in a single "named" graph, so it's 
ok if it wins majority.

> 6. In trig, @union can be used in place of the default graph
>     "@union<u>  {<a>  <b>  <c>}" entails turtle "<a>  <b>  <c>"

Yes, but I'd rather have @merge. There could be both. But as in 5., 
@merge could be implemented by making sure the bnodes are distinct in 
each "named" graph.

> 7. Datasets only say which triples are known to be in a named graph,
>     not which triples are *not* in that named graph.
>     The merge of "<u>  {<a>  <b>  <c>}" and "<u>  {<a>  <b>  <d>}" is
>     "<u>  {<a>  <b>  <c>,<d>}".


>     Also "<u>  {<a>  <b>  <c>,<d>}" entails "<u>  {<a>  <b>  <c>}".

Huh, aren't you saying the opposite of item 3 above?


Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 83 36
Fax:+33(0)4 77 42 66 66

Received on Wednesday, 25 April 2012 14:51:44 UTC