- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 16 Nov 2015 06:09:51 -0800
- To: Iovka Boneva <iovka.boneva@univ-lille1.fr>, public-data-shapes-wg@w3.org
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? >> 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. >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. > 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. 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. 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. peter
Received on Monday, 16 November 2015 14:10:31 UTC