Re: shapes-ISSUE-88 (labra): qualified values [SHACL Spec]

I think this issue illustrates the crux of the difference between ShEx
and SHACL. ShEx is based on a pattern matching paradigm similar to
string matching in regular expressions where instead of matching on a
string of characters it matches on a set of triples. We have been
trying to approximate this mechanism through the use of qualified
cardinality constraints.

Should we introduce a new property constraint combinator to replicate
the semantics of ShEx, e.g. like GroupShape in [1]? One of my concerns
about doing that is the performance implication. RegEx uses a greedy
algorithm which makes sense for strings since the characters are in a
sequence. However there is no ordering on triples, and it may happen
that a given triple satisfies more than one pattern. This can result
in a high computational complexity. On the other hand, real-world data
may have the characteristic of its triples only matching one pattern,
in which case the performance would be acceptable in practice.

I don't think performance should be the overriding consideration since
every query language, including SPARQL, lets you write arbitrarily
complex queries. I don't see why SHACL should impose a safety net on
constraints.

[1] http://w3c.github.io/data-shapes/semantics/

-- Arthur


On Sun, Sep 20, 2015 at 2:46 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> I realize now reading this that Jose's issue and my issue on repeated
> properties are very close to each other. They are both complicated by the
> use of a property with different values in the same focus node. Perhaps a
> single solution will work for both?
>
> Also, it makes more sense to me when I picture it as a graph. This made me
> realize that we have no graph drawings in our document, even though those
> are commonly used in RDF. This may be something we should think about for
> the primer.
>
> kc
>
>
> On 9/20/15 1:23 AM, Holger Knublauch wrote:
>>
>> On 9/11/15 9:40 PM, RDF Data Shapes Working Group Issue Tracker wrote:
>>>
>>> shapes-ISSUE-88 (labra): qualified values [SHACL Spec]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/88
>>>
>>> Raised by: Jose Emilio Labra Gayo
>>> On product: SHACL Spec
>>>
>>>
>>> The current spec contains qualifiedValueShape to represent that "a
>>> certain number values of the given property must have a given shape".
>>>
>>> That property can be used to emulate multi-occurrence of the same
>>> property with different value shapes. However, some use cases may
>>> require to express multi-occurrence of the same property with
>>> different values (not just value shapes).
>>>
>>> As a simple example, we may want to declare items that must have two
>>> codes, one with two digits and the other that starts with an uppercase
>>> letter.
>>>
>>> In ShEx, it can be represented as:
>>>
>>> <item> { :code PATTERN "\d{2}"
>>>         , :code PATTERN "^[A-Z]"
>>>         }
>>>
>>> However, AFAIK, is is not possible to represent this example in the
>>> current SHACL Spec.
>>>
>>> Possible solutions:
>>>
>>> 1.- Define a new property for that case, something like:
>>> sh:qualifiedValue maintaining the current qualifiedValueShape as it
>>> is. In that case, the previous definition would look like:
>>>
>>> :Item a sh:Shape;
>>>   sh:property [
>>>     sh:predicate :code;
>>>     sh:qualifiedValue [
>>>       sh:pattern "^[A-Z]"
>>>     ]
>>>     sh:qualifiedMinCount 1 ;
>>>   ] ;
>>> sh:property [
>>>     sh:predicate :code;
>>>     sh:qualifiedValue [
>>>       sh:pattern "\d{2}" ;
>>>     ]
>>>     sh:qualifiedMinCount 1 ;
>>>   ] ;
>>>   sh:property [
>>>     sh:predicate :code;
>>>     sh:minCount 2 ;
>>>     sh:maxCount 2 ;
>>>   ] .
>>>
>>> One problem having both "qualifiedValue" and "qualifiedValueShape" is
>>> that it would not handle the case where someone wants to have
>>> multi-occurrences that combine both.
>>>
>>> 2.- Replace qualifiedValueShape by qualifiedValue and support both
>>> value shapes and values. The example would be described as above.
>>>
>>> 3.- Ignore the use case.
>>>
>>> 4.- Adapt SHACL to have better support for multi-occurrence replacing
>>> the conjunctive semantics by additive semantics. In that case, the
>>> example could be defined as:
>>>
>>> :item a :Shape;
>>>   sh:property [
>>>     sh:predicate :code;
>>>     sh:pattern "\d{2}"
>>>   ] ;
>>>   sh:property [
>>>     sh:predicate :code;
>>>     sh:pattern "^[A-Z]" ;
>>>   ] .
>>
>>
>> Option 5 would be: Acknowledging that we cannot cover every possible use
>> case in the world via the core vocabulary, leave such cases for the
>> extension mechanism. The regular expression example that you give is
>> (easily) expressed via SPARQL.
>>
>> Holger
>>
>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>

Received on Friday, 25 September 2015 21:54:55 UTC