skosclass:depth

[Benedikt Kämpgen]

Hello,

I have another question regarding the extension of skos towards
classification hierarchies [1]. There, skosclass:depth is defined for
stating the depth of a level within a hierarchy. However, should it not be
possible to have the same level in different hierarchies on different
depths? In this case, the skosclass:depth of a level would need to be
attached to the hierarchy/skos:ConceptScheme. For that, skosclass:depth
would need to be reified using a class similar to ConceptAssociation.

I would be interested in your opinion on this.

Regards,

Benedikt

[1] <http://www.w3.org/2011/gld/wiki/ISO_Extensions_to_SKOS>

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
Email: benedikt...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en

[Richard Cyganiak]

Benedikt,

The depth property is for strongly stratified classifications such as NACE or NUTS, where knowing that a certain concept is on level 3 actually tells you something meaningful about the concept.

I wouldn't use ClassificationLevel and depth in concept schemes where the depth within the hierarchy isn't a meaningful part of the concept.

The domain of the depth property is ClassificationLevel. The depth is an intrinsic part of the level. If it was on a different level in a different hierarchy, then it is a different level and thus needs to be represented by a different ClassificationLevel resource.

Best,
Richard

[Benedikt Kämpgen]

Hello,

Coming (eventually) back to the discussion about having skosclass:depth as an inherent property of a ClassificationLevel, I have an example of where that might hinder reuse and compact representations of hierarchies:

If we have two hierarchies of the dimension date, from the least granular to the most granular ClassificiationLevel, and attached to it a skosclass:depth:

1) year (1) -> quarter (2) -> yearmonth (3) -> date (4)
2) year (1) -> week (2) -> date (3)

Another example would be:

1) country (1) -> state (2) -> county (3) -> city (4) -> store (5)
2) sales region (1) -> state (2) -> sales district (3) -> store (4)

In these cases, for date and store, we would need two ClassificationLevels that depending on the hierarchy would have different skosclass:depths. This would lead to many additional triples, since every date and store instance would need to be put in two different ClassificationLevels and it would not be possible to share date and store between hierarchies.

Is it possible to have a more compact representation, here?

Best,

Benedikt