- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 01 Jul 2015 15:23:34 -0700
- To: Arthur Ryman <arthur.ryman@gmail.com>
- CC: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Although the wording is not the best, I don't see that there is any necessary disconnect between these two. The first statement indicates that negshapes(S) is there to determine which shapes need to have full interpretations. The definition of negshapes(S) states, of which the second statement is one clause, says which shapes these are. It is not necessarily the case that shapes that participate directly in negation-based constructs are the only shapes that need to be in negshapes(S). Whether negshapes(S) is too big or too small is a separate matter. It may be that the clause you mention is unnecessary or unnecessarily broad. However, that can only be determined by a close examination of the entire language. peter On 07/01/2015 02:00 PM, Arthur Ryman wrote: > Peter, > > Thanks for the explanation. However, the spec also contains the > following statement: > > "Intuitively, negshapes(S) is the set of shapes labels for which one > needs to check whether some nodes in a graph do not satisfy these > shapes, in order to validate the graph against the schema S." > > This statement seems to contradict the clause I cited: > > "there is a shape label T1 and a shape triple constraint p::C, or an > inverse shape triple constraints ^p::C in expr(T1, S), and T appears > in C" > > In fact, the only aspect of the clause that narrows down the set of > all referenced shape labels is that it restricts the cardinality on > the shape expressions to [1,1] (since explicit cardinality is omitted > from p::C and ^p::C). I still think this in not what the authors > intended. > > -- Arthur > > > On Wed, Jul 1, 2015 at 12:32 PM, Peter F. Patel-Schneider > <pfpschneider@gmail.com> wrote: >> The semantics in http://w3c.github.io/data-shapes/semantics has an unusual >> treatment of negation. >> >> You should think of the semantics as providing partial interpretations for >> the shapes. However, certain shapes need a full interpretation so that >> negation can be handled. >> >> Which shapes need to be so treated? The shapes in negshapes(S). The >> definition of negshapes(S) is thus not directly related to negated shapes in >> S but is instead "those shapes that need a full intepretation". >> >> Are the definitions in the document adequate? I certainly don't know. Is >> the resultant semantics reasonable? I don't think so - see earlier posts. >> Can the resultant semantics be effectively computed? Probably not, as the >> check for a valid typing could involve looking at very many other typings. >> >> >> peter >> >> PS: It appears to me that the semantics as written allows for valid typings >> where both s and !s are on the label of some node in G. It may be that the >> way to fix this is to tighten the definition of typing. >> >> >> On 07/01/2015 07:33 AM, Arthur Ryman wrote: >>> Iovka/Eric, >>> >>> The semantics document [1] contains this clause in the definition of >>> negshapes(S): >>> >>> * there is a shape label T1 and a shape triple constraint p::C, or an >>> inverse shape triple constraints ^p::C in expr(T1, S), and T appears in >>> C. >>> >>> This looks wrong since there is no negation involved. Is this clause >>> correct? If so, please explain the reason for this definition. Thanks. >>> >>> BTW, I am working with the June 22 version, but I see that the latest is >>> June 30. What are you changing? I'd appreciate revision bars and >>> history. >>> >>> [1] http://w3c.github.io/data-shapes/semantics/#semantics_preliminaries >>> >>> -- Arthur >>>
Received on Wednesday, 1 July 2015 22:24:09 UTC