Re: Category vs skos:ConceptScheme

Hi Vladimir,

Another delayed answer...

The bottom line is that we didn't want to engage in too much SKOS modeling, as some people were not comfortable that dimensions or categories should be concepts in the first place.
In the detail.

> But this begs some questions:
> - why dqv:Category is a subclass of skos:Concept not skos:ConceptScheme?
>

Because categories can also be grouped into concept schemes (see later) and that we would like to allow category publisher to use SKOS matching properties (skos:exactMatch etc) to express links between different category systems, the same way as dimensions from different dimension systems would be matched together.
We expect there will be a big need for expressing such links, to enable some form of interoperability between quality frameworks.


> - what concept scheme(s) are supposed to be used for Category and Dimension
> individuals?


I'd expect concept schemes to represent provenance of dimensions and categories, and the belonging to a specific framework.
For example we could create two concept schemes 'ISO 25012 categories' and 'ISO 25012 Dimensions' for the categories and dimensions discussed at
http://w3c.github.io/dwbp/vocab-dqg.html#DimensionsOfISOIEC25012
And two concept schemes 'LDQD categories' and 'LDQD Dimensions' for the categories and dimensions discussed at
http://w3c.github.io/dwbp/vocab-dqg.html#DimensionsofZaveri



> - maybe dqv:inCategory should be subproperty of skos:broader?
>


We'd prefer to keep broader links 'available' for hierarchical links within dimensions or categories, rather than use them to cross streams. This could blur the (already not always easy to comprehend) distinction between dimensions and categories. Also, this would lead to questions on SKOS modeling, which as said we didn't want to go too much into. Expressing Data Quality on the Web is not a very mature domain with a lot of practice to refer to. Avoiding meta-modeling overcommitment seemed quite desirable.

Best,

Antoine


On 07/07/16 12:28, Vladimir Alexiev wrote:
>> Given that dqv:Dimension is subclass of	skos:Concept, I think that:
>> - dqv:Category should be subclass of skos:ConceptScheme
>> - dqv:inCategory should be subproperty of skos:inScheme
>
> (It's not good to answer my own email, and I should have read to the end
> before posting this, sorry)
>
> dqv:Category is a subclass of skos:Concept; so dqv:inCategory cannot be
> subproperty of skos:inScheme.
>
> But this begs some questions:
> - why dqv:Category is a subclass of skos:Concept not skos:ConceptScheme?
> - what concept scheme(s) are supposed to be used for Category and Dimension
> individuals?
> - maybe dqv:inCategory should be subproperty of skos:broader?
>
>
>
>
>

Received on Monday, 25 July 2016 14:14:05 UTC