Re: Splitting Part 1 and Part 2 in TOC

Hi!

Just a short comment to:

> SHACL users can only insert sh:OrConstraint into another shape.
> Compare to the other features, I believe it will be rarely used.

I guess e.g. in data integration scenarios (as I'm currently messing 
around using SHACL for those), sh:OrConstraints will be used quite often 
for modeling/checking weaving models that mediate between 2 models (if 
e.g. 1 concept on the LHS could be mapped to >1 concepts on the RHS 
based on its shape).

cheers

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-04-07 07:04, schrieb Holger Knublauch:
> On 4/7/2015 13:05, Karen Coyle wrote:
>> 
>> 
>> On 4/6/15 6:55 PM, Holger Knublauch wrote:
>> 
>>>> 
>>>> Holger, I am still trying to understand what this other category is.
>>>> AFAIK, SHACL defines constraints on nodes, properties (in a graph) 
>>>> and
>>>> the value(s) of those properties. Properties themselves can be 
>>>> subject
>>>> to constraints, mainly cardinality, but I don't see this clearly
>>>> called out in the document. I would prefer:
>>>> 
>>>> Constraints on nodes
>>>>   - cardinality ("only one person node allowed")
>>>>   - defined properties ("foaf:name")
>>> 
>>> I don't think we have core language elements for those two built-in
>>> right now (not sure what you mean with "defined properties").
>> 
>> Those defined in the SHACL expression with sh:property.
> 
> Ok, got it, that would be something like
> 
> sh:MyShape
>     sh:property [
>         sh:predicate ex:myProperty ;
>         rdfs:label "my property" ;
>     ]
> 
> with or without further restrictions. Just a way to state what is
> relevant for a shape. But then we need to start with that section, and
> not with sh:OrConstraint as you seem to prefer below.
> 
>> 
>>> 
>>>> 
>>>>   - Constraints on defined properties ("foaf:name")
>>>>      - cardinality
>>>> 
>>>>      - Constraints on property values (in this case, "foaf:name")
>>>>        -type
>>>>        - value list
>>>> 
>>>> This is, in fact, how the examples read, although none show
>>>> constraints on nodes.
>>> 
>>> I cannot tell whether such a further categorization would really help
>>> the logical flow. For example sh:hasValue sounds like it should be in
>>> the "property values" category, but it is really only firing a 
>>> violation
>>> if the focus node does *not* have that value. So the division here is
>>> IMHO not clear cut, and I'd vote for reducing the levels of nesting.
>> 
>> First, the names are all up in the air, so we can call things whatever 
>> we want.
>> 
>> I do think that the nesting is logical from the point of view of 
>> someone who intends to perform validation on their data. Again, I 
>> point to the structure of the DCMI DSP,[1] which has descriptions 
>> (nodes) and statements (properties). The DSP can have one or more 
>> descriptions, the description one or more properties. (Note that SHACL 
>> so far has nothing really equivalent to the Description Set Profile of 
>> DCMI, but again I think that may be something solved through a user 
>> interface.) The logical flow from the view of a data developer who 
>> wants to use SHACL to validate data is:
>> 
>> My data/metadata describes some "thing." First, I want to list the 
>> properties that I am declaring will be used to describe that thing. 
>> Let's say the thing is a book, and a book is described with:
>> 
>> dct:title
>> dct:creator
>> dct:date
>> 
>> Each of these can have specified cardinalities:
>> 
>> dct:title min=1 max=1
>> dct:creator min=0 max=unbounded
>> dct:date min=0 max=1
> 
> I'd welcome diffs from anyone, or even completely rewritten sections.
> I find it difficult to imagine how this would fit together well. For
> example did you notice that sh:hasValue also implies sh:minCount>0 ?
> So where to draw that line?
> 
>> 
>> That constrains the properties themselves, the triples that have that 
>> predicate. Once I've defined my properties, I want to say what type of 
>> object is "valid" for each one.
>> 
>> dct:title min=1 max=1
>>    valueType:literal
>> dct:creator min=0 max=unbounded
>>    valueType:URI
>>    [valid URI pattern: http://id.loc.gov/names/...]
>> dct:date min=0 max=1
>>    valueType:XMLSdate
>>    [valid values in range 1300-[present year + 1]]
> 
> BTW above you seem to be mixing sh:datatype, sh:valueType and
> sh:nodeKind/Type all into a single property "valueType".
> 
>> 
>> I see this as a constraint on the object, not a constraint on the 
>> predicate, but I'm not sure it matters how it is implemented in a 
>> SHACL engine as long as it is clear to those using SHACL and gives the 
>> result desired. Logically, one is constraining the object values in 
>> the instance data triples. (And, yes, it gets complicated with 
>> recursion, but I leave that issue to Peter.)
>> 
>> Those, to me, are the steps that a metadata developer will take, from 
>> the broadest listing of properties to the specific definition of 
>> validatable object values. SHACL needs to support that workflow, IMO, 
>> and the first part of the SHACL document should be logically organized 
>> around that workflow. That doesn't mean that SHACL *language* itself 
>> has to be nested -- but the documentation should make those points 
>> clear to the reader.
>> 
>> 
>>> 
>>>> Now, which of those does 4.0 refer to? And can we present SHACL with 
>>>> a
>>>> logical structure of this nature?
>>> 
>>> Section 4 is currently only hosting sh:OrConstraint, and that may 
>>> need
>>> to be in your "Constraints on nodes". I don't believe it would make
>>> sense to have that constraint type listed first, as it's usually just 
>>> a
>>> combination of other constraints.
>> 
>> No, I think it does make sense, because it is a constraint at the 
>> highest level of the design workflow. Do I have a person shape or a 
>> book shape? Do I have both? This is the big picture of the data that 
>> will be validated, and it's one of the first decisions that a designer 
>> needs to make. It may be that for a design of a SHACL engine it is 
>> made up of other constraints, but as we've said, the majority of SHACL 
>> users will be folks who are writing shapes to validate their data. So 
>> the workflow logic of those users should guide the first part of the 
>> document. And I think that workflow will go from the biggest picture 
>> the designer has of their data (a macro-level entity-relation sort of 
>> view), down to the details.
> 
> SHACL users can only insert sh:OrConstraint into another shape.
> Compare to the other features, I believe it will be rarely used. I
> don't understand why this would be part of the big picture - "Do I
> have a person shape or a book shape" is not answered by
> sh:OrConstraint, but rather by the instance pointing at its shape, via
> rdf:type or sh:nodeShape.
> 
> Holger

Received on Tuesday, 7 April 2015 05:33:07 UTC