Re: sh:allowedValues and skos:Collection

On 8/18/2015 10:13, Holger Knublauch wrote:
> On 8/18/2015 2:04, Miika Alonen wrote:
>> This is related to the ISSUE-80, but still separate matter.
>>
>> One way of referencing classifications etc. would be to create lists 
>> from existing concepts. However, if you create such lists then you 
>> should also describe how the list is created and add some human 
>> readable documentation to it. I tried to think of a way to validate 
>> data that references to members in skos:Collection. You could 
>> validate skos:Collections with skos:member using inverse property 
>> constraints, but skos:memberList is bit difficult. I tried to refence 
>> the same list (blank node) in both skos:memberList and 
>> sh:allowedValues but it seems that its a bad idea.
>>
>> Could it be possible to support instances of skos:Collection with the 
>> sh:allowedValues predicate? Allowed values could come from the list 
>> defined by skos:memberList. This would also mean that you could reuse 
>> the same value lists in multiple constraints. Same functionality 
>> could also be achieved by creating similar sh:Collection and 
>> sh:memberList to the SHACL specification.
>
> I believe this is technically no problem, although I would prefer to 
> introduce a new keyword such as sh:allowedValuesCollection. But a 
> question is whether SHACL can/should support on anything from the SKOS 
> namespace. SKOS is popular and well-established, and I think it would 
> be better to reuse skos:Collection instead of creating yet another 
> variation of it. However, the layering feels a bit weird for the SHACL 
> Core Language. For example, if we were to add SKOS constraints, then 
> why not schema:Enumeration or Hydra Collection?
>
> I don't want to sound like a broken record, but I believe such things 
> would be best handled by a separate SHACL vocabulary, such as 
> SHACL-SKOS. That library could also hold the other SKOS-related 
> constraints, such as those captured as User Story 21:
>
> http://www.w3.org/TR/2015/WD-shacl-ucr-20150414/#uc21-skos-constraints
>
> Such work could be outsourced to a corresponding special interest group.

FWIW I have ported the small SKOS library used by TopBraid from SPIN to 
SHACL, and this now also includes a template for allowed values based on 
SKOS collections, e.g.

skos-shacl-test:CollectionTestClass
   a sh:ShapeClass ;
   sh:property [
       a shskos:CollectionPropertyConstraint ;
       sh:allowedValuesCollection skos-shacl-test:OrderedCollection_1 ;
       sh:predicate skos-shacl-test:myProperty ;
     ] ;
.

skos-shacl-test:OrderedCollection_1
   a skos:OrderedCollection ;
   skos:member skos-shacl-test:A ;
   skos:member skos-shacl-test:B ;
   skos:member skos-shacl-test:C ;
   skos:memberList (
       skos-shacl-test:A
       skos-shacl-test:B
       skos-shacl-test:C
     ) ;
.

skos-shacl-test:CollectionTestInstance
   a skos-shacl-test:CollectionTestClass ;
   skos-shacl-test:myProperty skos-shacl-test:A ;
   skos-shacl-test:myProperty skos-shacl-test:Other ;  # Invalid
.

While doing this I got reminded that these two patterns happen quite 
frequently:

- shskos:DisjointPropertyPairConstraint (?predicate1, ?predicate2)
- shskos:UniqueLanguagePropertyConstraint (?predicate)

The WG may want to add those to the Core language, and I have opened two 
corresponding tickets to discuss their inclusion:

https://www.w3.org/2014/data-shapes/track/issues/81
https://www.w3.org/2014/data-shapes/track/issues/82

Holger