Linking to SKOSXL (following our call)

Ok, I'll try to be synthetic, still with some examples and a bit of
philosophy.I know I'll fail :-)

 

Premise; when things hardly match:

1)      We can try to guess the "intention" of the mapped models by
following their terminologies (names of classes, properties, their
descriptions etc..);

a.       pro: greater readability of the mapping, (hopefully) larger
"respect" of the intended identity of the entities; 

b.      contra: we have seen it even in our case: modeling is always a
discretization, and sometimes we may arbitrarily assign names which could
belong to two entities (because of their use through common sense), to one
instead of one another

2)      We can try to map the closest structures

a.       pro: free from "false friends" in the terminology

b.      contra: closeness in graph similarity does not mean closer semantics

 

Given the above, I initially too was tempted to go for: 

 

ontolex:Form rdfs:subClassOf skosxl:Label

 

a skosxl:Label after all is just a reified label. Not so different from a
ontolex:Form.

 

But, this way, we would have, in a certain sense, that skos:Concepts are
attached directly to forms.

 

Now, let's look at the full structure in skosxl:

 

<a_Skos:Concept> --> skosxl:xxxLabel --> <a_skosxl:Label >  -->
skosxl:literalForm --> <a_literal>

 

Intentionally, a label is an entry (as Thierry remarked too on the call
today), which is reified for the historical reasons of those thesauri-makers
who raised the need for SKOS: they wanted to attach metadata, historical and
editorial notes, to labels. They were not caring too much about language
details as we are, and for instance, the forms of these entries are not
reified in turn (we only have a skosxl:literalForm datatype property) as we
do through class "ontolex:Form".

The fact that a ontolex:LexicalEntry has many forms while skosxl:Label has
only one literalForm is partially explained by the fact that usually
(though, yes, not always) in thesauri we find only the *lemmas* of the many
lexical entries. AltLabels deal usually with really alternative lexical
entries (synonyms). Syntactic variations/morphology etc.. are usually (in
SKOS(/XL)) left to external software and lexical data sources. Some may
attempt to cover - usually arbitrarily and with lack of completeness - this
explosion of possibilities, but, that's the limit, usually either you are
good at thesauri, or at good at language, but you cannot in a complete and
sound way, cover both. We are in fact trying to decouple the two things with
Ontolex, and then let them be properly interfaced.

 

By following this "interpretative approach", I would say:

 

ontolex:LexicalEntry rdfs:subClassOf skosxl:Label

 

and thus (look at the matching variables):

 

for each structure like:

    <?x a ontolex:LexicalEntry>  --> ontolex:canonicalForm -->
<a_ontolex:Form>  --> ontolex:writtenRep  --> <?l a literal>

 

We have a corresponding:

    <?x a skosxl:Label>  --> skosxl:canonicalForm  --> <?l a literal>

 

where the reification of the ontolex:Form is simply lost (note that the
property chain in OntoLex cannot be axiomatized into being a subproperty of
skosxl:canonicalForm, as it ends with a datatype property.I really don't
understand the impossibility for having a datatype property at the end of
the chain.waiting for OWL3 ;-) )

 

At the same time, for each ontolex:Form bound through ontolex:otherForm , we
can only give indications on how to *generate* (if users are interested in
that) new labels. Obviously this is not a loss-less transformation, because
we are losing the binding among these Forms, as they produce skosxl:Labels
which are independent from each other. But this cannot be avoided, indeed
this is where SKOSXL left the thesauri publishers abandoned: in the spirit
of leaving a model agnostic with respect to the many modeling aspects and
theories of language, they just provided an abstract skosxl:labelRelation
object property, and didn't suggest any vocabulary establishing well known
lexical relationships.

 

My suggestion: we could coin ourselves one subproperty of of
skosxl:labelRelation, expressely thought for ontolex portings, in case one
would like to keep the information in ontolex. This property should inform
that a given label hosts actually an alternative form for an expression hold
by another label.

 

Again, remember that the second part, related to the *generation* of other
labels from "otherForms", can also be avoided.

 

Pref/alt/HiddenLabels?

 

Ah, to close everything nicely: since the implication is that only lemmas
(canonicalForms) of ontolex:LexicalEntries are de facto automatically
inferred (ok, still not possible, but that's the rule) as being the single
skosxl:literalForm skosxl:Labels, one could freely use:

 

skosxl:prefLabel,  skosxl:altLabel etc..

 

with any ontolex:LexicalEntry, as it is also a skosxl:Label! And that would
be *really* nice for satisfying easily the exigencies of thesauri
makers/publishers who would embrace our vocabulary.

 

Thus, we can derive from:

    <?c a skos:Concept>  --> skosxl:prefLabel --> <?x a
ontolex:LexicalEntry>  --> ontolex:canonicalForm --> <a_ontolex:Form>  -->
ontolex:writtenRep  --> <?l a literal>

The following:

    <?c a skos:Concept>  --> skosxl:prefLabel --> <?x a skosxl:Label>  -->
skosxl:literalForm --> <?l a literal>

 

As previously said, we cannot infer anything about the otherForms of ?x for
concept ?c, but again:

1)      people interested in having an ontolex-->skosxl export, could easily
decide to not export the otherForms, because they only want the Lemmas, and
this representation could provide a useful knife for deciding what to cut in
the export, by limiting the axiomatized inference to the lemmas.

2)      other (non-exclusive) solution is to generate altLabels from the
otherForms (yes, even from otherForms of an ontolex:LexicalEntry ) or, why
not? skosxl:hiddenLabels! Because hidden Labels represent exactly further
information which does not need to be shown (at the level of representation
of skosxl) but which should be kept for application dependent purposes.
Choice on altLabel/hiddenLabel could also depend on (possible) Form2Form
relationship or further qualification of Forms through properties different
from canonicalForm/otherForm (maybe subs of otherForm).

 

 

Sorry, very long, but had to be complete, and hopefully sound.

 

Armando