Fwd: Re: Added Requirement: Static Constraints

mis-sent only to Holger earlier

-------- Forwarded Message --------
Subject: Re: Added Requirement: Static Constraints
Date: Wed, 21 Jan 2015 16:53:14 -0800
From: Karen Coyle <kcoyle@kcoyle.net>
Reply-To: kcoyle@kcoyle.net
To: Holger Knublauch <holger@topquadrant.com>



On 1/15/15 8:09 PM, Holger Knublauch wrote:
> Hi Karen,
>
> I thought you wanted to express that within the same subject, dct:title
> could only have one value. This is what I outlined below.


Yes, that is correct. I hadn't understood that other aspect of the
primary key requirement.

  If you want to
> ensure that the same value is only used once per graph, then I guess you
> would need to rewrite the query to
>
> SELECT ?value
> WHERE {
>      ?subject1 dct:title ?value .
>      ?subject2 dct:title ?value .
>      FILTER (?subject1 != ?subject2) .
> }
>
> which would find all ?values that are used by two (or more) distinct
> subjects.

I don't know of a use case for this. The question, though, is how one
would express this without using SPIN - in other words, do we have a
generic way to express this requirement? I think it gets back to how one
defines to target of the validation. Because these two cases have two
different solutions, should they be different requirements?

Thanks,
kc


>
> The primary key design pattern is similar, but also includes a
> specification that can be used to automatically create the URI of a
> resource based on a property value (e.g.
> http://example.org/countries-USA if the primary key is "USA").
>
> Holger
>
>
> On 1/16/2015 13:48, Karen Coyle wrote:
>> Holger, it looks to me like the "primary key" requirement [1] covers
>> this. Do you agree?
>>
>> kc
>> [1]
>> https://www.w3.org/2014/data-shapes/wiki/Requirements#Declarations_of_Primary_Key_Properties
>>
>>
>> On 1/15/15 2:45 PM, Holger Knublauch wrote:
>>> On 1/16/2015 1:45, Karen Coyle wrote:
>>>> Thanks, Holger. As usual, I need to do this "by example" because it's
>>>> quite likely that my vocabulary differs from that of others here.
>>>>
>>>> Use cases: I have data that uses dct:title in various places, and I
>>>> want to say that wherever it is used it can only be used once for each
>>>> subject in my data. Here's some data:
>>>
>>> The following static constraint could express that scenario:
>>>
>>> ex:AtMostOneTitleConstraint
>>>      a :StaticConstraint ;
>>>      :message "For a given subject, dct:title can only be used once." ;
>>>      :predicate dct:title ;
>>>      :sparql """
>>>              # Find all subjects that have two distinct values of
>>> dct:title
>>>              SELECT (?subject AS ?root)
>>>              WHERE {
>>>                  ?subject dct:title ?title1 .
>>>                  ?subject dct:title ?title2 .
>>>                  FILTER (?title1 != ?title2) .
>>>              }
>>>          """ ;
>>> .
>>>
>>>>
>>>> 1)
>>>> subjectA dce:creator "Somebody" .
>>>> subjectA dct:title "Some title" .
>>>> subjectA bf:subject http://.... .
>>>> subjectB dce:creator "Someone else" .
>>>> subjectB dct:title "Another title" .
>>>>
>>>> 2)
>>>> subjectA dce:creator "Somebody" .
>>>> subjectA dct:title "Some title" .
>>>> subjectA bf:subject ex:subject1 .
>>>> subjectB dce:creator "Someone else" .
>>>> subjectB dct:title "Another title" .
>>>> subject1 dct:title "A related book" .
>>>>
>>>> That's a pretty stupid example, and the data is more sophisticated
>>>> than that, of course. My questions are:
>>>>
>>>> a) because this data does not use rdf:type (unless inferred, and let's
>>>> say it isn't), does subject "s" constitute a node/graph/shape?
>>>
>>> In the absence of an rdf:type triple, we indeed need to declare this as
>>> a static constraint that is not attached to any class but executed for
>>> the whole graph.
>>>
>>>> b) substitute "skos:prefLabel" here and a rule that skos:prefLabel can
>>>> occur only once per each "X" (X because I dont know what to call it) -
>>>> is that the same case?
>>>
>>> I think that's similar, only that we could probably associate that
>>> constraint with skos:Concept, because that is where skos:prefLabel is
>>> supposed to be used. However, skos:prefLabel should have another
>>> constraint that it should only have one value per language tag, which is
>>> a variation of the query above. Here is the corresponding SPIN query
>>>
>>> CONSTRUCT {
>>>      _:b0 a spin:ConstraintViolation .
>>>      _:b0 rdfs:label ?message .
>>>      _:b0 spin:violationRoot ?this .
>>>      _:b0 spin:violationPath skos:prefLabel .
>>> }
>>> WHERE {
>>>      ?this skos:prefLabel ?label1 .
>>>      ?this skos:prefLabel ?label2 .
>>>      FILTER ((lang(?label1) = lang(?label2)) && (?label1 != ?label2)) .
>>>      BIND (CONCAT("Constraint S14: a resource has no more than one value
>>> of skos:prefLabel per language tag (@", lang(?label1), ").") AS
>>> ?message) .
>>> }
>>>
>>>> c) is this really a new use case, or a variation on existing ones?
>>>
>>> I believe the Requirements cover this scenario. Whether you want to
>>> write it up as a new User Story is up to you.
>>>
>>> HTH
>>> Holger
>>>
>>>
>>
>
>
>

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

Received on Thursday, 22 January 2015 01:17:13 UTC