Re: propose to make repeated-properties additive

Holger,

I like your unification of the concepts. Now constraints on the focus
node are describe in the same way as constraints on the values of
properties (direct or inverse).

-- Arthur

On Mon, Sep 21, 2015 at 6:01 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> On 9/21/2015 10:50, Holger Knublauch wrote:
>>
>> On 9/21/2015 6:19, Karen Coyle wrote:
>>>
>>>
>>>
>>> On 9/20/15 1:39 AM, Holger Knublauch wrote:
>>>>
>>>> On 9/19/15 5:02 PM, Karen Coyle wrote:
>>>>>
>>>>> 2) repeated properties
>>>>> This is a real and not uncommon example:
>>>>>
>>>>>   <bf_Person1>
>>>>>   bf:identifiedBy <http://id.loc.gov/authorities/names/n80103961#RWO> ;
>>>>>     #IRI from id.loc.gov, min 1, max 1
>>>>>   bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> .
>>>>>     #IRI from viaf.org, min 1, max unlimited
>>>>
>>>>
>>>> I agree it makes sense to talk about the requirements before requesting
>>>> a change to the language. If I understand the intention correctly, then
>>>> the above could be expressed with an incremental addition to the core
>>>> library:
>>>>
>>>> ex:MyShape
>>>>      a sh:Shape ;
>>>>      sh:property [
>>>>          sh:predicate bf:identifiedBy ;
>>>>          sh:qualifiedMinCount 1 ;
>>>>          sh:qualifiedMaxCount 1 ;
>>>>          sh:qualifiedValueShape [
>>>>              sh:constraint [
>>>>                  a sh:URIPatternConstraint ;
>>>>                  sh:uriPattern "^http://id.loc.gov" ;
>>>>              ] ;
>>>>          ] ;
>>>>      ] ;
>>>>      sh:property [
>>>>          sh:predicate bf:identifiedBy ;
>>>>          sh:qualifiedMinCount 1 ;
>>>>          sh:qualifiedValueShape [
>>>>              sh:constraint [
>>>>                  a sh:URIPatternConstraint ;
>>>>                  sh:uriPattern "^http://viaf.org" ;
>>>>              ] ;
>>>>          ] ;
>>>>      ] .
>>>>
>>>> The new feature that would be needed would be sh:URIPatternConstraint -
>>>> the current sh:pattern only applies to property values "one hop away"
>>>> while here we would need something that talks about the IRI of the focus
>>>> node itself. We had a similar topic recently with regards to
>>>> sh:allowedValues. It may make sense to generalize the validation
>>>> function mechanism so that the same infrastructure can be reused, but in
>>>> the end this is about syntactic sugar only.
>>>
>>>
>>> In fact, the question was less about the URI pattern than about the
>>> ability to have different values for the same property, and to constrain
>>> them separately. So we should pick some other value constraints to use that
>>> SHACL already handles -- perhaps that the first instance is an IRI and the
>>> second is a literal.
>>
>>
>> Ok, this just highlights that we need more test cases. A property that can
>> (meaningfully) take either literals or IRIs as values is not a use case that
>> I have seen yet. I am aware that schema.org allows that, but schema.org can
>> afford that liberty because they have quite a lot of post-processing
>> machinery, e.g. to turn a country code string into a Country instance.
>>
>> Anyway, let's look at what it would take to express such things. I believe
>> we need to continue to keep general property constraints and qualified
>> property constraints separate, because the majority of constraints is not
>> qualified but applies to all values. In order to express your use case
>> above, we would need to extend the sh:qualifiedValueShape mechanism so that
>> it can also work with literals. Currently my implicit assumption was that
>> the focus node cannot be a literal, but this is probably an unnecessary
>> restriction. I have just opened a ticket for that micro decision.
>>
>> Then, we could more cleanly separate the concepts of property value
>> restrictions, and restrictions on the focus node itself. Taking sh:nodeKind
>> as an example, we could then describe your scenario using
>>
>> ex:MyShape
>>     a sh:Shape ;
>>     rdfs:comment "someProperty must have one IRI and one or more Literals"
>> ;
>>     sh:property [
>>         sh:predicate ex:someProperty ;
>>         sh:qualifiedMinCount 1 ;
>>         sh:qualifiedMaxCount 1 ;
>>         sh:qualifiedValueShape [
>>             sh:constraint [
>>                 sh:NodeConstraint ;
>>                 sh:nodeKind sh:IRI ;
>>             ]
>>         ]
>>     ] ;
>>     sh:property [
>>         sh:predicate ex:someProperty ;
>>         sh:qualifiedMinCount 1 ;
>>         sh:qualifiedValueShape [
>>             sh:constraint [
>>                 sh:NodeConstraint ;
>>                 sh:nodeKind sh:Literal ;
>>                 sh:datatype xsd:string ;
>>             ]
>>         ]
>>     ] .
>>
>> In the design above I have am suggesting a template sh:NodeConstraint
>> which combines the various node-related constraint types:
>>
>> - sh:allowedValues
>> - sh:class
>> - sh:datatype
>> - sh:directType
>> - sh:minLength
>> - sh:maxLength
>> - sh:nodeKind
>> - sh:maxExclusive etc
>> - sh:pattern
>>
>> All of these are backed by the same sh:ValidationFunctions as the property
>> constraints, so it's just another syntax for the same thing. (But we would
>> need to reopen the discussion on the naming of sh:valueClass vs. sh:class).
>>
>> Does this sound like the right direction?
>
>
> Yesterday I went further and implemented this mechanism for my API. It
> wasn't a lot of work and appears to work well. For the record, I believe
> this also resolves
>
> - ISSUE-84 (limit IRIs of focus nodes to enumeration)
> - ISSUE-88 (sh:qualifiedValue)
>
> Summary of suggested changes:
> - Rename sh:valueClass to sh:class
> - Rename sh:directValueType to sh:directType
> - Rename sh:allowedValues to sh:oneOf
> - Add sh:NodeConstraint with properties sh:datatype, sh:class, etc
> - Generalize sh:validationFunction to also work with NodeConstraintTemplates
>
> Then, all the built-in constraint properties such as sh:class can be used in
> 3 places:
>
> ex:MyShape
>     a sh:Shape ;
>     sh:property [
>         # Applies to all objects of the property
>         sh:predicate ex:someProperty ;
>         sh:class ex:SomeClass ;
>     ] ;
>     sh:inverseProperty [
>         # Applies to all subjects of the property
>         sh:predicate ex:someIncomingProperty ;
>         sh:class ex:SomeClass ;
>     ] ;
>     sh:constraint [
>         # Applies to the focus node itself
>         a sh:NodeConstraint ;
>         sh:class ex:SomeClass ;
>     ] .
>
> sh:NodeConstraint could also be called sh:FocusNodeConstraint and for
> consistency we could make it the defaultValueType of sh:constraint.
>
> Holger
>
>

Received on Friday, 25 September 2015 22:18:37 UTC