Re: How would option b) on the last straw poll of 12 March work?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/15/2015 05:39 PM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-03-15
> 12:55-0700]
>> A few questions and comments.
>> 
>> 
>> Is this the entirety of SHACL or just the core language?  The language
>> here does not cover closed shapes, exclusive or, global constraints,
>> maximum cardinality of 0, non-datatype type matching, or datatype
>> facets.
> 
> Agreed, it seemed wisest to start with a conservative subset and add.

The problem is that adding may be problematic or impossible.  How, for
example, is this account going to handle closed shapes or global constraints
or extension via SPARQL code?

> What is "non-datatype type matching"?

Matching against a RDF type (RDFS class).

> 
>> What happens with cardinalities that are not integers, e.g., 
>> "3.1"^^xsd:double.
> 
> Is it worth enumerating the behavior in case of schema violations?

This doesn't appear to be a violation.

> Does OWL say what happens with <X> :allValuesFrom "abcd"?

Yes, it is a syntax error and thus undefined.

>> Several of the RDF examples don't match the abstract syntax, e.g., 
>> my:UserShape.
> 
> Can you point me a little closer at the mismatch?

Shapes have "zero or one triple constraints" but my:UserShape has two.

>> What happens if a node encodes both a property constraint and an and 
>> constraint, or any of the the other combinations?  What happens with 
>> structure sharing, e.g., a sh:property and sh:inverseProperty link to
>> the same node?
> 
> I think half of the answer is in the RDF parsing rules. How does OWLs 
> Mapping to RDF graphs handle this?

OWL requires that each node be uniquely translatable into an OWL axiom.

> I wouldn't expect disjoint axioms to prevent this in e.g. RL. That said,
> we could have OWL schema that enumerations disjunctions and if people
> author schemas with violate them, that's their problem.

The problem is that there is nothing in the description that prevents this
sort of situation.

>> What is the basic operation in SHACL?  Does it take one RDF graph, one
>> RDF dataset, or multiple RDF graphs and datasets?
> 
> So far, 6. Matching only defines matching for a `focus node` in an RDF 
> graph. I expect we'll want more expressivity in the core language once we
> gather use cases from e.g. Jeremy Carroll.

There are a bunch more questions to be answered.  One is whether
sh:nodeShape and the shape have to be in the same RDF graph as the data
being matched.


>> What is evaluation of a term?  What happens if there are multiple
>> values?
> 
> fixed "property constraint matches" to read [[ The "matching triples" is
> the set of triples in the graph with the subject node of the `focus node`
> and a predicate of the `property constraint's` predicate.  Evaluation of
> a property constraint produces true if each of the following is true:
> 
> If the property constraint has a `minimum cardinality` greather than 0, 
> the `matching triples` number at least that minimum cardinality.
> 
> If the property constraint has a `maximum cardinality` greather than 0, 
> the `matching triples` number no more than that maximum cardinality.
> 
> If there is a `term constraint` present, for each object in `matching
> triples`, that object matches (see 6.2…). ]]

This doesn't speak to "evaluated term" or multiple property values in 6.2.

> That last condition could also reference a "term constraint matches" 
> analogous to "triple constraint matches" to serve as the prototype for 
> `note type matches`, `datatype matches`, `value set matches`, `value 
> shape matches`. Your advice?

There needs to be something to tie the objects/subjects at the beginning of
6.2 to the things being checked against in the body of 6.2.  This is a place
where formal definitions are easier to comprehend.

>> The specification appears to be ill-founded on recursive shapes over
>> data loops.  I can't tell for sure because there is no formal basis.
> 
> We can add a set visited:([node,shape]) to the shape matches function to
> provide an opperational strategy for eliminating infinite recursion. Is
> that useful in the this semantics?

Well something is needed.  Otherwise it is not possible to determine what
should be happening.

peter


>> 
>> On 03/14/2015 05:34 PM, Eric Prud'hommeaux wrote:
>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-03-12 
>>> 13:56-0700]
>>>> There were a number of WG members who voted for: b) The main 
>>>> specification shall include the higher-level language constructs
>>>> only and the rest shall be defined in add-ons.
>>>> 
>>>> Can any one describe how this option would work?  Would there be a 
>>>> single way of defining the meaning of the entire language (main
>>>> spec and add-ons) or would there be several ways of the defining
>>>> what constructs mean?
>>> 
>>> As a down-payment, I offer 
>>> <http://w3c.github.io/data-shapes/semantics/>. I hope to produce a
>>> start on an axiomatic semantics and a SPARQL semantics tomorrow.
>>> 
>>> 
>>>> peter
>>>> 
>>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVBjDkAAoJECjN6+QThfjztIsIAND6b+20oyWhZ05oY6XGzVl7
8vhpXe9weG8j9OVrFmv2n3Hf2dZ9NODjaNWHDVNTnOYUyWRgKEkHvSxxwZptbem9
mNuEkFWyStSB2ZCe4TO1r16kSCROGD9JuOr2uV9tzyUXGFw1BY7asR0brtd5LGdO
yj3Xbbjn5UOvR84SpQOswdPxL2ylY/GNW85Ccz2MflEiugkmn1oOA/tUvU4ZIcVH
ut1y7dJHnrc5XukGRRDruLyT0Bkyy0SnzRx+hhQ9TqwmLZQ2a3L4jHK/evyyKL5V
b4ylKhWKVyCdAPY3ZSND/hFjQ++qBMiJnFHHyAvXIdjIY+jcT7rv+H8/QcRE/8E=
=fXWr
-----END PGP SIGNATURE-----

Received on Monday, 16 March 2015 01:25:21 UTC