Comparing Term-as-class and n-ary annotation solutions
Solutions are presented on SkosDesign/RelationshipsBetweenLabels
Foreword on adequacy of solutions
Both solutions enable to represent the information that is needed, and both allow for extendability (which is not the case with current model)
Positive and negative aspects of Term-as-class vs n-ary annotation
[I adapted/extended these from the initial material mentioned in SkosDesign/RelationshipsBetweenLabels]
Positive aspects:
- simplicity of modeling
- easily capturing the arity of term links (a solution with binary properties vs. a solution which was intended to represent non-binary relations)
- easily representing the direction of term links, when these are directed (using RDF subject/object distinction, and not artificial hasSource/hasTarget)
- allows for easily specifying useful semantics on the links (e.g. symmetry of translation link)
- avoids redundancy of "representing" a same label several times in disconnected way
- lighter representation
- easier to manage when labels are updated
Negative aspects:
- most retrieval purposes are already covered by the existing model
- complexity of modeling simple labelling situations (i.e., covered by existing model), and getting the info for it (more complex RDF graphs, more complex queries)
- difficulty of dealing with simple labelling semantics for application (equality of labels would need OWL inverseFunctional)
- diluting the concept-centric modelling stance of SKOS
losing the ease of using XML language tags for (xml:lang) multilingual labelling
- losing the identity of Labels with same 'value' which is trivially obtained with plain literals. Unless we equip SKOS with appropriate semantics, and we *heavily* advertise it
a possible solution would be to introduce a specific property for the literal value of a term/label, and to declare it owl:InverseFunctionalProperty, but for a datatype property this leads to OWL Full
notice that RDF also defines equality condition for literals, cf http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-plain-literal
losing the possibility to declare SKOS labelling properties as specializations of rdfs:label and therefore all label-based functionalities of tools only aware of this property (which might be a blessing indeed: on a modelling level, rdfs:label is just meant for labelling while altLabel and prefLabel have real conceptual value)