- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 17 Nov 2015 04:37:29 -0500
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Iovka Boneva <iovka.boneva@univ-lille1.fr>, public-data-shapes-wg@w3.org

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-11-16 06:09-0800] > On 11/16/2015 12:36 AM, Iovka Boneva wrote: > > Le 13/11/2015 19:33, Peter F. Patel-Schneider a écrit : > >> On 11/11/2015 07:50 PM, Arthur Ryman wrote: > >> [...] > >>> Iovka said that the draft is no longer being maintained. Her latest > >>> version of the semantics of ShEx is given in [1]. I pointed out that I > >>> had proposed a different approach to positive recursion. [2] > >>> > >>> We agreed to look at each others articles and decide how to proceed. > >>> > >>> [1] http://arxiv.org/abs/1510.05555 > >>> [2] http://arxiv.org/abs/1505.04972 > >> [...] > >> > >> I am continuing to look at [1]. > >> > >> > >> > >> It appears to me that ShEx there is *not* built on top of RDF, as the notion > >> of a graph there allows triples whose predicate is the inverse of a property. > >> This permits a different set of graphs than does RDF because the three graphs > >> below are different > >> > >> 1/ > >> :a :p :c . > >> :c ^:p :a . > >> > >> 2/ > >> :a :p :c . > >> > >> 3/ > >> :c ^:p :a . > >> > >> I am puzzled as to why this change was introduced. > > This is not a change, just an abstraction on RDF graphs. Because 2/ and 3/ and > > not abstraction of any correct RDF graph, they will never be considered. > > I agree that 2/ and 3/ are not the abstraction of any RDF graph, but > analysis of the ShEx here will be complicated because the formal system that > it works over has these extra graphs. Why introduce this gratuitous > difference from RDF? I'm not sure if you're saying that the formalism doesn't keep distinct the bnodes in an RDF graph or if it doesn't cover a higher-level model like OWL where identity is distinct from URL and bnode labels. For the latter, ShEx, like SPARQL, works over RDF graphs. For the former, note that neighborhood and witnesses are in terms of nodes (including blank nodes). The point that val(some blank node) = _b is only used to slightly increase the expressivity by providing a semantics for a bnode in an enumerated value set, namely that it is satisfied by any bnode in a triple. I'm marking with [graphval] all of the questions which I'm hoping are addressed by this. > >> As well, there appears to be a single designated value for all blank nodes, so > >> that it is not possible to distinguish between > >> > >> 4/ > >> :a :p _:b1 . > >> :a :p _:b2 . > >> _:b1 :p :c . > >> _:b2 :p :d . > >> > >> and > >> > >> 5/ > >> :a :p _:b1 . > >> :a :p _:b2 . > >> _:b1 :p :c . > >> _:b1 :p :d . > >> > > In the abstraction, nodes still have unique identifiers, and two blank nodes > > are not the same. > > I think that the construction is ambiguous. I was thinking that val formed > a unique identifier for the nodes. On closer reading of the construction, > it is possible that this is not the case. This opens up the further > divergence from RDF graphs where two distinct nodes share the same IRI or > literal. [graphval] > >From [1], "The value function val associates, with every node in Nodes, > either an IRI, or a literal value, or a special value _b that stands for a > blank node." "For all blank node B that appears in some triple, there is a > nodeB in Nodes such that val(nodeB) = _b." > > I read this as saying that the same node was used for each blank node, > because they all have the same val. These nodes *could* be different, but > there is nothing to prevent *some* blank nodes from sharing the same node. > So I guss that the intent is to have a unique graph node for each blank > node, but there is nothing so saying. [graphval] > > The 4/ and 5/ graphs above will be distinct, because in 4/ > > there will be two different nodes for _b1 and _b2, that are n_b1 and n_b2, > > respectively. > > See above. Nothing prevents there being a single node for both _b1 and _b2, > i.e., n_b1 = n_b2. > > > The fact that val(n_b1) = val(n_b2) = _b is not a problem, > > because in ShEx there is nothing to distinguish between the local ids of two > > blank knodes anyway. > > There is another problem in the construction, however. The predicates of > triples not transformed into graph nodes, but stay the same. This may not > affect ShEx directly, as long as no manipulations are performed on the graph > that can relate predicates of triples with nodes in the graph, but it does > cause a divergence as soon as such manipulations are possible, e.g., in RDFS > inferencing. > > I also note that literals in triples are not handled at all. I expect that > this is simply an oversight. Also, I expect that you meant "literal" > instead of "literal value" as part of the range of val. yup, thanks. > There is also no requirement that a graph corresponding to an RDF graph is > minimal. Neither is there any proof that the minimal graphs corresponding > to an RDF graph produce the same results in ShEx validation. Both of these > are probably just oversights. [graphval] (or note that the result is T/F) > I do not see the point of this abstraction process, however. Why not just > use RDF graphs as defined in the RDF specification instead of going through > this exercise? If you need something like val, perhaps to ensure blank-node > indistiguishability, you can just define it directly on RDF graphs. We used an abstraction of RDF graphs in order to treat incoming and outgoing edges uniformly, thus avoiding us to distinguish two cases (incoming, outgoing) in every single definition or theorem. > peter > > -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.

Received on Tuesday, 17 November 2015 09:37:38 UTC