Re: an alternative proposal for partition

On 8/11/16 11:05 PM, Holger Knublauch wrote:
> I think this will come down to a general design choice. Do we want to
> add this very complex feature to the SHACL Core, or do we simply point
> people at the SPARQL extension mechanism. QCRs cover quite a number of
> use cases. Not every use case will be nicely expressible this way, but
> then OTOH many people already know SPARQL and use it every day for these
> very kinds of complex queries. Why do we need to reinvent everything
> into a higher-level language,

For the people who do not know SPARQL at that level. - kc

  esp given that - without doubt - someone
> else will request yet another design pattern that is not covered by our
> core language even with the most general sh:partition feature. We need
> to stop somewhere.
>
> In SPARQL, the check for your scenario could be something like (untested):
>
> SELECT ?this
> WHERE {
>     FILTER NOT EXISTS {
>         ?this dc:creator ?mil .
>         FILTER regex(?mil, "^mailto:.*@b.mil") .
>         ?this dc:creator ?gov .
>         FILTER (regex(?gov, "^mailto:.*@a.gov") ||
>                 EXISTS { ?gov foaf:mbox ?mbox . FILTER regex(?mbox,
> "^mailto:.*@a.gov") })
>     }
> }
>
> and we don't need to reinvent further wheels. You can even combine these
> with existing SHACL shapes, using sh:hasShape. Or you can make this
> nicer with SHACL functions, e.g.
>
> SELECT ?this
> WHERE {
>     FILTER NOT EXISTS {
>         ?this dc:creator ?mil .
>         FILTER ex:isMilEmail(?mil) .
>         ?this dc:creator ?gov .
>         FILTER (ex:isGovEmail(?gov) || EXISTS { ?gov foaf:mbox ?mbox .
> FILTER ex:isGovEmail(?mbox) })
>     }
> }
>
> which is IMHO quite an acceptable Compact Syntax, only far more general.
>
> Holger
>
>
> On 12/08/2016 11:01, Eric Prud'hommeaux wrote:
>> * Holger Knublauch <holger@topquadrant.com> [2016-08-11 17:14+1000]
>>> This looks like quite a mega feature, if sh:and and sh:or become
>>> overloaded
>>> with very different meaning, requiring a new execution algorithm etc.
>>> What
>>> about spawning this off into an extension, just like the SPARQL stuff
>>> is in
>>> an extension?
>>>
>>> Another option is to handle this on the Compact Syntax level, and
>>> produce
>>> QCRs under the hood. Are there any scenarios where QCRs could not (in
>>> principle) express your use cases?
>> The QCRs are relatively simple to generate but the universal
>> constraint is problematic. Taking the 2nd example below with a
>>
>> shexc:
>>    <S> {
>>      (   dc:creator PATTERN "^mailto:.*@a.gov"  # either creator a.gov
>>        | dc:creator {                           # or a creator some node
>>            foaf:mbox PATTERN "^mailto:.*@a.gov" # with a foaf:mbox of
>> a.gov
>>          }
>>      ) ;
>>      dc:creator PATTERN "^mailto:.*@b.mil"     # and one b.mil creator
>>    }
>>
>> dc:creator which may be an email or a bnode with a foaf:mbox, we can
>> compose and additional universal constraint which limits the objects
>> of dc:creator to the three enumerated forms:
>>
>> shacl:
>>    <S>
>>      sh:and (
>>        [ sh:or (
>>    #   dc:creator PATTERN "^mailto:.*@a.gov"  # either creator a.gov
>>          [ sh:property
>>            [ sh:predicate dc:creator ; sh:pattern "^mailto:.*@a.gov" ;
>>              sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>     ] ]
>>    # | dc:creator {                           # or a creator some node
>>    #     foaf:mbox PATTERN "^mailto:.*@a.gov" # with a foaf:mbox of a.gov
>>    #   }
>>          [ sh:property
>>            [ sh:predicate dc:creator ; sh:shape [
>>           sh:property
>>             [ sh:predicate foaf:mbox ; sh:pattern "^mailto:.*@a.gov" ;
>>                    sh:minCount 1; sh:maxCount 1
>>         ] ] ; sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>     ] ]
>>        ) ]
>>    #   dc:creator PATTERN "^mailto:.*@b.mil"     # and one b.mil creator
>>        [ sh:property
>>          [ sh:predicate dc:creator ; sh:pattern "^mailto:.*@b.mil" ;
>>            sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>        ] ]
>>    # universal constraint to handle closure
>>        [ sh:or (
>>          [ sh:property
>>            [ sh:predicate dc:creator ; sh:pattern "^mailto:.*@a.gov" ;
>>              sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>     ] ]
>>          [ sh:property
>>            [ sh:predicate dc:creator ; sh:shape [
>>           sh:property
>>             [ sh:predicate foaf:mbox ; sh:pattern "^mailto:.*@a.gov" ;
>>                    sh:minCount 1; sh:maxCount 1
>>         ] ] ; sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>     ] ]
>>          [ sh:property
>>            [ sh:predicate dc:creator ; sh:pattern "^mailto:.*@b.mil" ;
>>              sh:qualfiedMinCount 1; sh:qualfiedMaxCount 1
>>          ] ]
>>        ) ]
>>      ) .
>>
>> This gets us part way there, but round-tripping may be impossible and
>> it doesn't provide the OneOf OR behavior has described in the
>> foaf:name example below. A typical example from clinical data (FHIR)
>> analog to the (name|givenName,familyName) example would involve making
>> sure that an osteoporotic spiral fracture had either a single
>> component with a compound code ("46675001|73737008") or two
>> components, each with one of those codes. For instance, ShEx's
>> partitioning semantics allows us to easily capture this error:
>>
>>    <Obs1> a fhir:Observation ;
>>      fhir:component
>>        [ fhir:code "46675001|73737008" ],
>>        [ fhir:code "46675001" ].
>>
>>
>>> Holger
>>>
>>>
>>> On 11/08/2016 11:32, Eric Prud'hommeaux wrote:
>>>> The current partition meets some additive use cases like:
>>>>    <S> {
>>>>      dc:creator PATTERN "^mailto:a.gov" ; # one a.gov creator
>>>>      dc:creator PATTERN "^mailto:b.mil"   # and one b.mil creator
>>>>    }
>>>>
>>>> but not ones with any algebraic operators like:
>>>>    <S> {
>>>>      (   dc:creator PATTERN "^mailto:.*@a.gov"  # either creator a.gov
>>>>        | dc:creator {                           # or a creator some
>>>> node
>>>>            foaf:mbox PATTERN "^mailto:.*@a.gov" # with a foaf:mbox
>>>> of a.gov
>>>>          }
>>>>      ) ;
>>>>      dc:creator PATTERN "^mailto:.*@b.mil"     # and one b.mil creator
>>>>    }
>>>>
>>>> An alternative which would be to create a syntax to capture ShEx's
>>>> partition semantics which say:
>>>>    Map the triples to the triple patterns with the same predicate.
>>>>    The node is valid with respect to a triple expression if there
>>>>    is a mapping of triple to triple pattern which satisfies the
>>>>    expression.
>>>> For instance, the data
>>>>    <s> dc:creator <mailto:a@b.mil> .
>>>>    <s> dc:creator _:b1 .
>>>>    _:b1 foaf:mbox <mailto:b@a.gov> .
>>>> satisfies the above pattern.
>>>>
>>>> I propose leveraging the current partition but allowing expressions:
>>>>    <S> sh:partition [
>>>>      sh:and (
>>>>        [ sh:property [
>>>>            sh:predicate ex:creator ; sh:minCount 1 ; sh:maxCount 1 ;
>>>>       sh:pattern "^mailto:.*@a.gov" ] ]
>>>>        [ sh:property [
>>>>            sh:predicate ex:creator ; sh:minCount 1 ; sh:maxCount 1 ;
>>>>       sh:pattern "^mailto:.*@b.mil" ] ]
>>>>      ) .
>>>>
>>>> This also handily provides a semantics with a disjunctive OR so e.g.
>>>>    <EmployeeShape> {
>>>>        foaf:name .          # either a foaf:name
>>>>      | ( foaf:givenName . ; # or a pair of givenName
>>>>          foaf:familyName .  # and familyName
>>>>        )
>>>>    }
>>>> would not be satisfied with a partial pair:
>>>>    <emp1> foaf:name "Alice Cooper" .
>>>>    <emp1> foaf:familyName "Cooper" .
>>>> because the 1st disjoint doesn't use the 2nd triple and the 2nd
>>>> disjoint is missing a familyName.
>>>>
>>>> Users wanting either additive properties or disjunctive OR could
>>>> use the sh:partition operator.
>>>>
>>>
>
>
>

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

Received on Friday, 12 August 2016 22:15:28 UTC