W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Fwd: Re: Added Requirement: Static Constraints

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 21 Jan 2015 17:43:25 -0800
Message-ID: <54C055BD.6060406@gmail.com>
To: kcoyle@kcoyle.net, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think that in OWL constraints this can be handled as

HasKey( owl:Thing () ( dct:title ) )

which states that dct:title is a key for things.

peter




On 01/21/2015 05:16 PM, Karen Coyle wrote:
> 
> 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
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwFW9AAoJECjN6+QThfjzpxIIAMVMQCZMdQrTKnvskDyLkSS2
G2x0NNMN7NdRHgDCG+Hh0lzSk0XfZ0XS5htcZlyJjOvuuepZqyUZ7suXbBnMJXnT
KIB/71sBKP5xe/GZaVGc8NYo7PMGjNAA9J9jSHc3javvXpaDSI9384nHJ07vcLyw
Ui0XUUhg7tL0W+8PzQIMZLokQBi32f+kBUtwMF95e3haRmJgOCVWZQKOnSSrfC8Q
e7Ry6dg+bCXz2uaWgFUQEBQH7Dlbym/IceXQ+jo+lIfppviyb6nllZ6n6LhC7ITF
oYhjK6QTTgd05ispinMHMfQxv44BU06E5cEfv+RXmMKDEnhWlLnfpAP1sOk5Jik=
=9kud
-----END PGP SIGNATURE-----
Received on Thursday, 22 January 2015 01:43:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 January 2015 01:43:57 UTC