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

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

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? 
Is there any case when a target is not ignored when in a sub-graph of a 
sh:filterShape?

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.

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.

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.


>
> 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 Monday, 24 October 2016 16:13:48 UTC