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

cherry-picking the easy stuff 'cause i'm rather late for bed.

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

Closed shapes can be implemented if `triple constraint matches`
returns a set of passing and failing triples and `shape matches`
subtracts the passing from the failing, returning true if their are no
more failing triples. `and constraint matches` returns all of the
passing and failing and `or constraint matches` returns those from the
passing disjuncts.

As far as I can tell, global constraints are a query selection
mechanism à la <http://w3c.github.io/data-shapes/semantics/#h-issue2>.


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

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


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


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


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


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

I completely agree. If we can adopt some sort of formal definition,
I'd expect my text obselete or relegated to descriptions of the productions.


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

Fair enough. I'll cook some text up tomorrow. It would be nice to work
out in advance some form strategy for negation e.g. stratification. Do
you have an approach that yields a reasonably intuitive behavior for:

<Sh1> { !:p1 @<Sh1> }

? Can you cook up a reallistic example to check the intuition?


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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Monday, 16 March 2015 02:07:08 UTC