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

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.

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

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

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

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

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

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

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 25 October 2016 18:06:34 UTC