Re: Added Requirement: Static Constraints

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. 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.

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
>>
>>
>

Received on Friday, 16 January 2015 04:13:14 UTC