Re: shapes-ISSUE-192 (Are focus nodes shapes?): Should focus nodes be of type sh:Shape? if not, then what?

On 26/10/2016 4:05, Karen Coyle wrote:
>
>
> On 10/24/16 11:07 PM, Holger Knublauch wrote:
>>
>>
>> On 25/10/2016 2:13, Karen Coyle wrote:
>>>
>>>
>>>
>>>
>>> On 10/20/16 10:29 PM, Holger Knublauch wrote:
>>>> The description of the ISSUE-192 now states
>>>>
>>>> Filter shapes are currently defined as a subclass of sh:Shape
>>>>
>>>> which is not correct. There is no subclass of sh:Shape in SHACL.
>>>
>>> Then I misunderstood what you meant when you said:
>>>
>>> "The thing that I dislike about filter shapes is that they
>>> introduce a non-monotonic construct where subclasses can have fewer
>>> constraints than superclasses. This makes the whole language quite
>>> unpredictable."
>>> (https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0085.html) 
>>>
>>>
>>>
>>> Perhaps you were referring to the subclass relationship between
>>> sh:Shape and sh:Constraint?
>>>
>>>>
>>>> In general, I don't understand what this issue is about. I see no
>>>> problem with the fact that certain properties of a resource are 
>>>> ignored
>>>> depending on the context. In this case, sh:targetXY are ignored if a
>>>> shape is evaluated as a filter shape. The situation may have to be
>>>> explained better, but I see no technical issue, and to me at least the
>>>> current wording is quite clear.
>>>
>>> For reference, sh:filterShape is defined thus:
>>>
>>> sh:filterShape
>>>     a rdf:Property ;
>>>     rdfs:label "filter shape" ;
>>>     rdfs:comment """
>>>         This property links a constraint to shapes that the focus
>>> nodes need to fulfill before the constraint is evaluated.
>>>         """^^rdf:HTML ;
>>>     rdfs:domain sh:Constraint ;
>>>     rdfs:range sh:Shape ;
>>>     rdfs:isDefinedBy sh: ;
>
> One other thing here that is a bit confusing is that sh:filterShape is 
> of domain sh:Constraint. However, it is in the section on shapes (2.) 
> which reads:
>
> Shapes
> - Targets
> - Filter shapes
> - Constraints
>
> It may make more sense if filter shapes are placed under constraints 
> since they are often referred to in the text as performing a 
> "validation". Also, if constraints are not themselves shapes then I'm 
> not sure what unifies section 2.

Yes that's not good. I have changed the title of section 2 to "Shapes 
and Constraints" to better indicate what the section is about. It could 
also be something like "Basic Concepts of SHACL".

>
> Note that the first sentence of filter shape (2.2) says that the 
> filter shape is a shape: "A filter is a shape in the shapes graph that 
> further refines the focus nodes in the data graph that are validated 
> against a constraint or all the constraints of a shape."

Hmm well, that's formal language - I don't see a mistake but it's not 
very readable. This is the general conflict that we have as editors: 
some people tell us they want it more formal and others tell us they 
want it more readable. It's not always possible to have both. If in 
doubt, I am afraid I'll have to stick with the formal language and leave 
the rest to other material. I welcome diffs with better prose.

>
> (I admit to being thoroughly confused in this section.)
>
>
>>>
>>> The range of sh:filterShape is sh:Shape. However ...
>>>
>>> "Targets are ignored when a shape is processed as a referenced shape
>>> in parameters of shape-based constraint components (i.e. sh:shape),
>>> logical constraint components (i.e. sh:or) or, filter shapes
>>> (sh:filterShape)." (2.1)
>>>
>>> And here's an example of the formal definition of a target:
>>>
>>> sh:targetObjectsOf
>>>     a rdf:Property ;
>>>     rdfs:label "target objects of" ;
>>>     rdfs:comment """
>>>         Links a shape to a property.
>>>         The shape must be satisfied by all objects of triples that
>>> have the given property as its predicate.
>>>         """^^rdf:HTML ;
>>>     rdfs:domain sh:Shape ;
>>>     rdfs:range rdf:Property ;
>>>     rdfs:isDefinedBy sh: ;
>>>
>>> First, in the above description of targets, I'm not clear what
>>> "referenced shape in parameters of shape-based constraint components"
>>> means. When is a shape "referenced"? ("Referenced" is not defined.)
>>> Are these parameters the same as the constraint parameters defined in
>>> 2.3?
>>
>> I have clarified in the spec that they are values of these parameters.
>
> If I have understood this sentence:
>
> Targets are ignored when a shape is processed as a value of parameters 
> of shape-based constraint components (i.e. sh:shape), logical 
> constraint components (i.e. sh:or), or filter shapes (sh:filterShape).
>
> ... then I believe it can be said more clearly as:
>
> Targets MUST be ignored in the values of shape-based constraint 
> components (i.e. sh:shape), logical constraint components (i.e. 
> sh:or), or filter shapes (sh:filterShape).
>
> ("values" might be said as "value nodes" to get across the graph 
> nature of that)

No this would not be correct. The key is the context. The targets are 
only ignored if it is being *processed* as a value. A shape may also be 
executed stand-alone, as an entry point into the validation.

>
>>
>>> Is there any case when a target is not ignored when in a sub-graph of
>>> a sh:filterShape?
>>
>> I don't understand this sentence. What is a sub-graph of sh:filterShape?
>
> See clarification below.
>
>>
>>>
>>> Second, in the examples, in every case sh:filterShape has a blank node
>>> as its object, and that blank node has sh:property as its predicate.
>>> (sh:property is of type sh:Shape) If there are other possibilities, it
>>> would be good to define them and show them in examples. If this is the
>>> only possibility, it might be best to describe sh:filterShape in this
>>> way, rather than saying what it isn't.
>>
>> In my opinion, it will be more common than not to use blank nodes for
>> these filter shapes. We only have two examples of filterShape right now.
>> I think it would be a hint in the wrong direction if we include an
>> example where a filter shape is also a "global" IRI resource. More
>> generally, we have plenty of features that are only described using
>> either bnodes or IRIs. We cannot print every combination. I think since
>> we are nowhere excluding IRIs, the reader can hopefully infer that these
>> nodes may be IRIs too.
>
> Sorry, I wasn't clear. My question is not about the blank node, but 
> the predicate - sh:property. Are other predicates possible? If so, it 
> would be good to show at least one other predicate as an example. As 
> we know, people assume a lot from examples.

The values of sh:filterShape are shapes, so I hope it's clear that these 
shapes may use other constraint components beside sh:property. I 
disagree this needs to be repeated each time.

>
>>
>>>
>>> Third, it would be good to describe this exception where
>>> sh:filterShape is defined, not elsewhere in the document. The
>>> information about a property needs to be found at or very near the
>>> definition of the property. Obviously it can be a forward reference,
>>> but one can't count on users making the connection when information is
>>> spread apart in the document.
>>
>> Could you suggest a specific "diff"? I am unclear what you are referring
>> to. For now, I have added the following sentence to the section on
>> filter shapes:
>>
>> ---
>> Note that during the validation against filter shapes, the <a
>> href="#targets">targets</a> of these filters are ignored.
>> ---
>>
>
> "Targets as values of filter shapes MUST be ignored."
> or
> "When targets are values of filter shapes, they MUST not be 
> applied/MUST be ignored."
>
> ("are" is a statement of fact, not a directive.)

See above, this would be incorrect.

>
>>
>>>
>>> Fourth, this exception means that the RDF vocabulary does not describe
>>> the actual range of sh:filterShape since the four target properties
>>> that are excepted are indeed of type sh:Shape. Therefore, it would be
>>> good to have clarity on what the relationship is between the RDF
>>> vocabulary and the SHACL document. As an example, Dublin Core has a
>>> concept of application profiles where an application can build on a
>>> more general vocabulary, further refining values, setting
>>> cardinalities, etc. SHACL Core is beginning to look a bit like such a
>>> profile in relation to the RDF vocabulary. I'm not sure that works,
>>> but it's worth a thought.
>>
>> I cannot see an error in the RDF vocabulary. The range of sh:filterShape
>> is sh:Shape, which means that RDFS-aware tools may infer that its values
>> are instances of sh:Shape.
>
> No, it's not an error. I was hoping, I suppose, for an RDF vocabulary 
> that could function as more of an explanation of SHACL, but I see that 
> is not the case. Because I find the text to be unclear, I was grasping 
> for clarity in the RDF vocab.

The rdfs:comments in the RDF file had been written ages ago (mostly by 
Arthur). They may no longer reflect the current design. I will clean 
that up once we are getting closer. My plan would be to copy and paste 
agreed-upon sentences from the spec into these comments. Doing this 
right now would be just duplicate work.

Holger



>
>
> DC application profiles are described here:
> http://dublincore.org/documents/profile-guidelines/
>
> and the formal definition (which was never really completed, but was 
> what Tom Baker and I described at the original shapes meeting) is here:
>
> http://dublincore.org/documents/dc-dsp/
>
> This is what motivated DC to participate in this group.
>
> kc
>
>
> I don't understand what you are referring to
>> with regards to application profiles.
>>
>> Latest change set:
>>
>> https://github.com/w3c/data-shapes/commit/119775926511c3e90b4a39df8bb8abea8a4b4eeb 
>>
>>
>>
>> Holger
>>
>>
>>>
>>>
>>>>
>>>> XSD seems to have something very similar:
>>>>
>>>>     https://www.w3.org/TR/xmlschema11-1/#xsi_type
>>>>
>>>> https://www.liquid-technologies.com/xml-schema-tutorial/xsd-extending-types#xsi-type 
>>>>
>>>>
>>>>
>>>> The xsi:type attribute can be used by any XML "instance" document to
>>>> explicitly state that a certain element (=node) has a certain type
>>>> (=shape). This is despite the fact that the same XSD type may be
>>>> referenced from other types within its own document. So in a sense, 
>>>> this
>>>> is also overriding the default use of the given XSD type with a direct
>>>> pointer.
>>>
>>> I don't think that XML functionality is relevant to RDF vocabularies.
>>>
>>>>
>>>> On the comment that I gave earlier, that filter shapes introduce 
>>>> issues
>>>> such as non-monotony: if anyone else sees this as a problem too, I 
>>>> would
>>>> be happy to drop sh:filterShape and replace it with a flag sh:disabled
>>>> true. The meaning of that would be that an engine would always return
>>>> "valid" if a node is validated against a shape that is marked to be
>>>> disabled. This covers our use case (of locally disabling certain 
>>>> shapes
>>>> or constraints that happen to be imported) and would support scenarios
>>>> where people want to temporarily switch off certain shapes or
>>>> constraints during development without having to delete them.
>>>
>>> I see this as only worsening the problem of consistency and 
>>> conformance.
>>>
>>> kc
>>>
>>>>
>>>> Regards,
>>>> Holger
>>>>
>>>>
>>>> On 21/10/2016 5:16, Karen Coyle wrote:
>>>>> Yes, it was too late in a day when I was up at 5am. I'll edit the
>>>>> issue. Thanks,
>>>>> kc
>>>>>
>>>>> On 10/19/16 3:13 PM, Holger Knublauch wrote:
>>>>>> I think you are mixing up focus nodes and filter shapes. Could you
>>>>>> rephrase?
>>>>>>
>>>>>> Holger
>>>>>>
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>>> On 20 Oct. 2016, at 6:41 am, RDF Data Shapes Working Group Issue
>>>>>>> Tracker <sysbot+tracker@w3.org> wrote:
>>>>>>>
>>>>>>> shapes-ISSUE-192 (Are focus nodes shapes?): Should focus nodes 
>>>>>>> be of
>>>>>>> type sh:Shape? if not, then what?
>>>>>>>
>>>>>>> http://www.w3.org/2014/data-shapes/track/issues/192
>>>>>>>
>>>>>>> Raised by: Karen Coyle
>>>>>>> On product:
>>>>>>>
>>>>>>> Focus nodes are currently defined as a subclass of sh:Shape and are
>>>>>>> referred to in the document as shapes.
>>>>>>>
>>>>>>> In the abstract syntax, this looks like:
>>>>>>>
>>>>>>> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape],
>>>>>>> constraints:Set[Test]
>>>>>>>
>>>>>>> Given that sh:filterShape has a range of sh:Shape, the logical
>>>>>>> conclusion here is that a filter can theoretically have targets,
>>>>>>> filters, and constraints.
>>>>>>>
>>>>>>> However, the document says this in 2.1 Targets:
>>>>>>>
>>>>>>> "Targets are ignored when a shape is processed as a referenced 
>>>>>>> shape
>>>>>>> in parameters of shape-based constraint components (i.e. sh:shape),
>>>>>>> logical constraint components (i.e. sh:or), filter shapes
>>>>>>> (sh:filterShape) or, for SHACL Full, in the evaluation of the
>>>>>>> sh:hasShape SPARQL function."
>>>>>>>
>>>>>>> I interpret this as meaning that range of sh:filterShape does not
>>>>>>> have the same qualities as the class sh:Shape. If this is the case
>>>>>>> then this doesn't follow the RDF definition of class membership.
>>>>>>>
>>>>>>> Holger said this in an email:
>>>>>>>
>>>>>>> "In general I do have concerns about the concept of filter shapes.
>>>>>>> They
>>>>>>> are a nice-to-have syntactic short cut, esp to manipulate existing
>>>>>>> shape
>>>>>>> definitions, but otherwise their effect can be achieved via sh:and
>>>>>>> already. The thing that I dislike about filter shapes is that they
>>>>>>> introduce a non-monotonic construct where subclasses can have fewer
>>>>>>> constraints than superclasses. This makes the whole language quite
>>>>>>> unpredictable."
>>>>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0085.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Karen suggested that filters could be retained as their own "beast"
>>>>>>> by defining a new class (sh:Filter)  type sh:Filter would take only
>>>>>>> constraints as an object.
>>>>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0072.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> However, now that sh:Shape is a subclass of sh:Constraint, the 
>>>>>>> range
>>>>>>> of sh:Constraint is pretty much everything, so there isn't a class
>>>>>>> that can be used in a more narrow sense.
>>>>>>>
>>>>>>> Irene said:
>>>>>>> "<In terms of predictability, having a filter shape able to include
>>>>>>> shapes, targets, and filters is less predictable than having a 
>>>>>>> filter
>>>>>>> constraint that cannot also have shapes, targets and filters. One
>>>>>>> avoid
>>>>>>> the potential for a kind of infinite churning of shapes within 
>>>>>>> shapes
>>>>>>> within shapes.>"
>>>>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0082.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>

Received on Wednesday, 26 October 2016 06:30:15 UTC