Re: Linking to SKOSXL (following our call)

Armando, all,

  thanks a lot for this careful and on-the-point expostion (not long at 
all!)

I like the proposal very much indeed. It seems very elegant to me that 
LexicalEntries can be used as SKOS labels by people who have SKOS 
thesauri and need more linguistic expressivity. That's a nice feature 
indeed! I had not thought about this.

The inferences you propose are partially not possible in OWL, but I do 
not see this as a problem for now. One can always do some more 
procedural reasoning to to these inferences (e.g. by SPARQL Construct 
for instance).

The only issue I see is that LexicalEntry would inherit the following 
restriction: restriction on|skosxl:literalForm 
<#literalForm>|cardinality exactly 1

But I think this can be justified by clearly stating that 
skosxl:literalForms are different from our Forms.

We could indeed infer the literalForm from the canonicalForm (possible)? 
but this might lead to inconsistencies as we infer a different from that 
the one specified.

I propose we talk about this on the telco on Nov. 8th.

Any opinions on this, please shout!

Enjoy the public holiday tomorrow, there will be no ontolex telco tomorrow.

Regards,

Philipp.

Am 25.10.13 18:47, schrieb Armando Stellato:
>
> 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:/other/Form , 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
>


-- 

Prof. Dr. Philipp Cimiano

Phone: +49 521 106 12249
Fax: +49 521 106 12412
Mail: cimiano@cit-ec.uni-bielefeld.de

Forschungsbau Intelligente Systeme (FBIIS)
Raum 2.307
Universität Bielefeld
Inspiration 1
33619 Bielefeld