- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 17 Dec 2014 08:26:09 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
On 12/17/2014 8:12, Karen Coyle wrote: > Thanks, Holger. I want to bring this back to the requirements on our > list, to make sure that they are clear. We have two requirements that > I can see, but I don't know if they address this completely: > "Expressivity: Language Tags" "Expressivity: Literal Value Comparison"? > > So for example, if you do not allow duplicate literal values for > dc:subject, you can have: > > dc:subject "foo"@en > dc:subject "foo"@fr > dc:subject "bar"@fr > dc:subject "foo" > > There are no literal value duplicates in this group. Is this case > covered in "literal value comparison"? > > In this next case, the question isn't duplicate values, but duplicate > language tags, regardless of the string portion of the literal value: > > skos:prefLabel "foo"@en > skos:prefLabel "foo"@fr > skos:prefLabel "bar"@fr > > The two "@fr"'s violate the restriction. > > In the DC use cases, we have yet another case, where two properties > cannot have the same literal value: > > dc:title "foo"@en > edm:title "foo"@en > > One of these would be eliminated as a duplicate. > > Do the two requirements sufficiently define these cases? Yes the requirements cover sufficient expressivity so that patterns such as those above can be expressed (e.g. in SPARQL). Since there are too many such patterns it would not be the right level of abstraction to spell them all out, as long as the underlying language can cover them. Example scenarios are best written up in the User Stories, and the SKOS constraints are one such story. Holger
Received on Tuesday, 16 December 2014 22:29:14 UTC