Re: disjointness between property constraint and inverse property constraint and default value type in the core

On 28/03/2016 22:58, Peter F. Patel-Schneider wrote:
>
> On 03/28/2016 02:04 AM, Holger Knublauch wrote:
>> On 25/03/2016 6:49, Peter F. Patel-Schneider wrote:
>>> On 03/24/2016 01:33 PM, Holger Knublauch wrote:
>>>> On 25/03/2016 5:39, Peter F. Patel-Schneider wrote:
>>>>> The current spec says in Section 2.3 that sh:PropertyConstraint and
>>>>> sh:InversePropertyConstraint are disjoint.  Is this a statement of truth, or
>>>>> is it something that has to be verified?
>>>> We have in general not yet decided how to handle various invalid shape graphs,
>>>> e.g. what errors are reported where. The first step would be to write down (in
>>>> the spec) what is invalid. A second step could be to define metashapes to
>>>> verify those. If someone finds other scenarios that need to be marked as
>>>> invalid, please raise them as issues.
>>>>
>>>>> The definition of disjoint only depends on rdf:type and default value type.
>>>>> This is a different definition of classes than in the rest of SHACL.
>>>>>
>>>>> Default value types appear to be part of the extension mechanism.  However,
>>>>> they have effect in the core.  This appears to indicate that implementations
>>>>> of the core need to implement at least this part of the extension mechanism.
>>>> The abstract *concept* of default value types is used by the core, while the
>>>> specific property sh:defaultValueType may not be needed by the core.
>>> There is no definition of the concept of default value type in the document.
>> I have attempted to define it better
>>
>> https://github.com/w3c/data-shapes/commit/bd690e4a513015d3856dec141cf6eb4317921c10
>>
>>
>> Holger
>>
>>
> This now depends on the undefined notion of "untyped".

In the end, the whole document is just a collection of words. At some 
stage a human reader is expected to have a certain background to be able 
to parse these words.

Holger

Received on Monday, 28 March 2016 21:22:22 UTC