Re: How to distinguish unique and non-unique prefLabels?

On Wed, Jan 12, 2011 at 11:43 AM, Jakob Voss <jakob.voss@gbv.de> wrote:


> Yes, 'zxx' is not very intuitive. At the moment I think that the best
> solution is to use skos:prefLabel unique, but some concept schemes will not
> have preferred labels, so there is a skos:Concept without this property.
> Instead you could add rdfs:label, but then the application does not know
> which rdfs:label to use as the main heading. As dc:title is also a
> sub-property of rdfs:label, we could use dc:title instead. But I am not
> comfortable with creating unique labels, if the scheme just does not have
> unique labels. SKOS applications should be able to deal with concepts that
> have no skos:prefLabel and with schemes that have non-unique
> skos:prefLabels.
>

A skos:Concept is not required  to have a prefLabel (SKOS §5.6.4); in fact,
a Concept is not required to have any labels at all.  There are no
cardinality constraints on the range of  prefLabel at all.  Z39.19 does not
require all term records to contain a term (Z39.19 §11.1.4; node labels are
encouraged in §7.7 );  I believe the ISO 2788 is similar, but I do not have
a copy to hand.

It is very useful to be able to have anonymous concepts, as  Jakob notes.
 Anonymous concepts give very simple solutions to two of the simpler cases
of compound terms; where a term is split into "USE A or B", and when a term
is split into "USE A and B"

In the OR case, an anonymous concept can be created with the original label
as an hidden Label, with a concept  prefLabeled A and a concept prefLabelled
 B added as narrower terms.

In the AND case, an anonymous concept can be created with the old term as a
hiddenLabel, and with A and B as broader terms.

This preserves the semantics (though in the former case, documents still
referring to the old term will require disjunctive reasoning).  Labels for
display can be generated by concatenating the preferred labels of all
directly narrower terms, separated by the equivalent of OR in the
appropriate language.

The absence of a preferred label can in fact be a good indicator that a
concept is not authorized for use (since it would not be possible to use it
in printed form).   References to concepts with no preferredLabel can
indicate a need to update the reference - automatically for conjunctions;
intelligently in the case of disjunctions.

The restriction to a single prefLabel for a given language for a given
concept scheme is a MUST under the requirement for ISO 2788 (and Z39.19)
compatibility.

The restriction is not enforced in the RDFS/OWL specification; I think it is
possible to get most of the way there  using HasKey (ignoring lang-tag for a
second)

HasKey(skos:Concept
      (skos:inScheme)
      (skos:prefLabel))

Unfortunately, because only properties can be used in hasKey axioms, the
lang-tag facet cannot be used, so this only works for monolingual thesauri.


The problem  can be avoided by using xl labels, making the language tag a
property of the label, and adding a HasKey on the xl lablel for literal
value and reified lang-tag.

DataProperty(skosxl:hasLanguage)
DataPropertyDomain(skosxl:hasLanguage skosxl:Label)
DataPropertyRange(skosxl:hasLanguage xsd:language)
SubClassOf( skosxl:Label
            DataExactCardinality( 1
                          skosxl:hasLanguage) )
HasKey(skosxl:Label (skos:inScheme) (skosxl:literalForm skosxl:hasLanguage))

Labels can be declared inScheme, and since they might have scheme specific
attributes, it seems safer to make them sameAs concept relative

Simon