W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

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

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Mon, 16 Mar 2015 05:46:09 -0700
Message-ID: <5506D091.2020601@gmail.com>
To: Eric Prud'hommeaux <eric@w3.org>
CC: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Hash: SHA1

[Closing off some of the dialog.]

On 03/15/2015 07:07 PM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-03-15
> 18:24-0700]
>> 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.


>>> What is "non-datatype type matching"?
>> Matching against a RDF type (RDFS class).
> Is that just?: [[ <SH> sh:property [ sh:predicate rdf:type ; 
> sh:allowedValue some:type ] . ]]


>>>> 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.
> sh:minCardinality a owl:DatatypeProperty ; rdfs:range xsd:integer .
> would restrict at the concrete language level, though perhaps you mean to
> restrict in the abstract syntax. What's OWL do?

The syntax for OWL requires these to be integers.

>>> Does OWL say what happens with <X> :allValuesFrom "abcd"?
>> Yes, it is a syntax error and thus undefined.
> ahh, CE denotes a class expression; DR denotes a data range; _:x
> owl:allValuesFrom T(CE) . _:x owl:allValuesFrom T(DR) . that makes
> sense.


>>>> 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.
> It's actually got one constraint, which is an `and constraint`, as noted 
> in the TODO at the bottom of Table 1. Transformation to Triples.

OK, but this needs to be done, as the table indicates otherwise.

>>>> 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.
> Perfect, can re-use that.

You have to be very careful here.  Allowing both ands and property
constraints to attach directly to a shape could cause problems.

>>> 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.
> "uniquely translatable" appears to handle this.

If done right, probably.

>>>> 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.
> Interesting, I guess this was true for OWL which means I always have to
> futz around creating little RDF files that owl:import some instance data
> and their corresponding ontology. Copying from OWL would be an 
> opportunity to reproduce that pain in SHACL.
> If we didn't say anything, would that encourage validators prompt for 
> both schema and instance like implementations for other schema
> languages?

Good question.   My suggestion is that there be two input graphs - one for
control and one for data.  This handles the unified case by using the same
graph for control and for data.


Version: GnuPG v1

Received on Monday, 16 March 2015 12:46:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:17 UTC