Re: LC Comments: Classification Schemes

Hi Sean, Alistair,

> Michael Panzer's comments [1] have raised a number of issues. As these 
> concern classification schemes, Alistair and I would be grateful if we 
> could have your input to possible resolutions (we note that Antoine 
> has already commented on some of these). In particular, we'd like to 
> hear your opinions on:

Here are my two cents on these issues, including the pointers to the 
ones I already reacted to.

>
> * ISSUE-181

This is again related to the issue of skos:Collections that cannot be 
included in concept hierarchies.
If Michael's "centered entities" really cannot be modelled as 
Collections, then indeed the only choice would be to represent them as 
skos:Concepts.
Note that if we had accepted the requirement 
R-IndexingAndNonIndexingConcepts [3] we could have proposed a solution 
to this. Indeed I guess that Michael's "non-assignable" concepts can be 
likened to what I called "non-indexing concepts" (if we ignore the fact 
that Michael's entities also have a skos:Collection flavour).
Still, as the requirement of having an indexing property in SKOS has 
been dropped, we have (rightfully) dropped this one as well.
Therefore, given the current state of SKOS, what I would recommand is 
for Michael to make his own solution to 
R-IndexingAndNonIndexingConcepts. That is:
- first identify an indexing property he wants to use to assign concepts 
to other resources (e.g. dc:subject).
- second, define a subclass of skos:Concept, e.g. 
my:NonAssignableConcept, which is defined as not being usable as the 
object of statements involving the chosen indexing property. This can be 
done in OWL  using a property inverse of the indexing one, in an 
appropriate OWL cardinality constraint.


> * ISSUE-182

I have nothing to add to what I already answered in [2] :-)

> * ISSUE-183

I found this comment hard to understand. Of course I would represent 
relations between classes as relation between skos:Concepts standing for 
these classes. But I don't get what "subjects/topics" are, if these are 
different from classes.
Without better understanding of the context I'd consider these topics to 
be specializations of classes. Therefore they could be represented as 
concepts attached to by the "class concepts" they belong to by 
skos:broader and narrower. But again I might have completely missed this 
comment. Especially without further examples of classes/topic, I cannot 
see for which reason there could be cycles :-/

> * ISSUE-184. Second issue in particular

Another issue I'm not sure of understanding entirely. To me it is 
perfectly possible to represent alternative notations as skos:altLabels. 
What altLabel and prefLabel allow to do in SKOS is considering semantic 
"equivalence classes" (in the mathematical sense of the expression) of 
labels, classes which are considered as true concepts. And the semantic 
relationships just hold at the level of concepts, not of labels. The 
same happens for alternative and preferred notations. The only 
difference being that for alternative notations, I expect these to be 
also usable as identifiers of concepts (no two concepts have a same 
notation) while this may not be the case for altLabels in general. But 
that does not raise any inconsistency in the concept scheme that results 
from using altLabel to represent alternative notations!

> * ISSUE-185. First half in particular

I guess there is no other solution than using RDF lists for representing 
ordered classes. Usual RDF statements are of course completely 
order-blind. The problem is so inherent to RDF itself that I think it 
would be counter-productive for us to propose a solution for this. 
Especially since this use case was after all not clearly identified 
beforehand. I think we're here in a case where standardization concerns 
dictate our not offering a specific solution.

Note however that there exist a way to (maybe somewhat indirectly) 
address Michael's specific problem, namely using a second layer of SKOS 
collections to represent the order of the classes in the class 
specialization hierarchy, as the following example:
ex:class rdf:type skos:Concept .
ex:subclass1 rdf:type skos:Concept ; skos:broader ex:class .
ex:subclass2 rdf:type skos:Concept ; skos:broader ex:class .
_:b0 rdf:type skos:OrderedCollection;
  skos:prefLabel "ordered subclasses of class1"@en; # this is optional 
of course!
  skos:memberList _:b1.
_:b1 rdf:first ex:subclass1 ;
  rdf:rest _:b2.
_:b2 rdf:first ex:subclass2 ;
  rdf:rest rdf:nil.

Of course that's not utterly convienent from a representational 
perspective. Nor can we ensure it would be adopted for all other 
classifications represented in SKOS. But at least it is exactly how 
Collections should be used in current SKOS :-) (as collections cannot be 
included in the semantic relationship hierarchy, they have to be used 
"in parallel" to semantic links between concepts)


> * ISSUE-186

I still adhere to the position I had in [4]. I am in favour of 
uncoupling mapping links and semantic relationships, and think we should 
limit SKOS to the represention of simple mappings links, focused on the 
"semantic flavor" of the relationship itself.

I hope this helps, please say if you think I should re-write some of 
these elements myselves as potential answers to Michael's comments!

Cheers,

Antoine


>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0061.html

[2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0131.html
[3] http://www.w3.org/TR/SKOS-UCR#R-IndexingAndNonIndexingConcepts
[4] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0132.html

Received on Monday, 13 October 2008 16:09:42 UTC