Re: Shapes - sub-classes / sub-properties

On 7/17/2014 19:09, Jose María Alvarez Rodríguez wrote:
> 1-SKOS validation. Although there are a good number of APIs, parsers, 
> etc. of SKOS-based vocabularies we have found that some of the 
> constraints in the recommendation cannot be easily checked. That is 
> why as a proof of concept we have implemented a SKOS validator [1] (it 
> is still on-going work) mixing ShEx, a reasoner and some SPARQL 
> queries. The motivation of this validator is just to know if all SKOS 
> concepts in a scheme accomplish with the expected shape. We are not 
> trying to develop a complete solution to check data quality but just 
> to ensure that if someone is going to reuse a SKOS vocabulary the 
> shape of the concepts is going to be the same. For instance we have 
> found a problem to validate that "S13skos:prefLabel, skos:altLabel and 
> skos:hiddenLabel are pairwise disjoint properties." this means that 
> these properties cannot have the same value. I am not sure if it is 
> possible to check it with SPIN, Pellet ICV or OWL restrictions but for 
> sure it is not possible in ShEX (actually this is a constraing in 
> values-content not structure) and we finally created a SPARQL query to 
> do that. Anyway my point here is that we only want to easily ensure 
> and maybe share the structure, template or shape of the concepts 
> without entering in other constraints or logical restrictions.

We had published a SPIN version of the SKOS constraints several years 
ago. For example open TopBraid Composer Free Edition and find the file 
TopBraid > SKOS > skosspin.spin.ttl . Constraint S13 is represented 
there via three instances of a SPIN template. Here is an older article 
on this work:

http://topquadrantblog.blogspot.com.au/2010/08/how-to-find-skos-constraint-violations.html

These constraints have been in routine use for many years in the 
TopBraid Enterprise Vocabulary Net (EVN) product line (SKOS editor etc).

Holger