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

-----BEGIN PGP SIGNED MESSAGE-----
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 ] . ]]

Probably.

>>>> 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.

yup.

>>>> 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.

[...]

peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVBtCRAAoJECjN6+QThfjzuu4IANZCVSmy/UGSW0Loakxu/Cvd
D48wjzZ3/tQuIjksq/e7SoV5HFB4xjvCd7PyNnZlwEhxoMBu8bS2gYEfVXgHbKlu
m6fcAn7sMJ7Ud2U57sRT1CtW8AW7Haw7kn/PGZRyU4aaGG+5oevs7LLvapxdVSHr
cQ9xA7hsBGSAPcIRvNDwOsqg+iFArZILKbl7sF/OtACB7c+UNNKtVIT3OMJY5OEi
kaG3JjxMMquimCqmS0XybOPM3+Dp87EqbSKHk9BSYpeCmmKdprFffOGDcsZapmb0
E+KKMoo3XxJyYTbYn4cdCizn/5gpDGD1vMdYQ3XwBzuRZ/pCY2pioBFXukiGlQQ=
=h8dD
-----END PGP SIGNATURE-----

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