Re: identity of SKOSXL labels

Dear Armando,

In SKOS-XL if two instances of xl:Label have the same literalForm, then it does *not* follow that they are the same resource.

This was in fact the subject of a lot of discussions in the making of SKOS. We investigated quite in depth the alternatives, but couldn't come with a strong motivation for coming with an 'identity rule'. In fact it seems dangerous to enforce identify of resources from identity of literalForm.

Quoting this year's paper on the design of SKOS: (http://dx.doi.org/10.1016/j.websem.2013.05.001)
[
Two concerns that arose during discussions of modeling alternatives for label relations were: identity conditions (When are two instances of the class skosxl:Label the same individual?), and the formal relationship between the class skosxl:Label and the set of RDF plain literals (Can instances of the class skosxl:Label have more than one literal form?). The working group decided to assert that instances of skosxl:Label have exactly one literal form in order to avoid ambiguity, but that sharing a common literal form should not be sufficient to infer that two instances of the class skosxl:Label were the same individual. In other words, two distinct instances of skosxl:Label might have the same literal form; there is no one-to-one mapping between the class extension of skosxl:Label and the set of RDF plain literals.
]

I don't remember all the arguments then. But one was clearly that the identity rule could harm interoperability with the kind of ontology-lexicon models you're refering to. When mapping these models to SKOS(-XL), it may make sense to represent as different resources two lexicon entries that would have a same literal form. For example for a words that is polysemous. I'm not saying that this should be the reference representation of such models in SKOS-XL, but we certainly didn't want to forbid such scenarios!

Also, from a pragmatic perspective, having the identity rule would have made xl:Label really close from being a reified version of rdfs:Literal. I.e., it would have practically allowed a trick to have literals as subject of statements). This might have had some consequences stretching quite far away the group's original mandate (representing KOSs in a basic way, not offering alternative to low-level RDF representation issues).

Cheers,

Antoine

On 1/2/14 8:05 PM, Armando Stellato wrote:
> Hi Johan,
>
> yes my bad I forgot to mention also the Appendix B of skos core, which I already read in the past, and in fact much of the doubts remain.
>
> By re-reading that section, I may confirm that it is not guaranteed that, given two skosxl:Labels with the same literalForm, these are the same resource.
>
> However, this “is not guaranteed” does not allow me to infer at all if SKOSXL enforces that C1 and C2 **should** have their own distinct labels, or if different modeling choices may allow the same URI to be used for labels with same literal form belonging to different concepts. The question is if, though reified, in a certain sense, the label remains “an appendix of the concept” or has (may have) a life of its own.
>
> The request may seem fussy, but here are two scenarios for which it is important to determine the above:
>
> 1)Compatibility with ontology-lexicon models, such as the one being developed here: http://www.w3.org/community/ontolex/
> Clearly, if same entries from a lexicon can be attached to more concepts, such models would be totally incompatible (not possible to specify rdfs:subClassOf rels) with skosxl:Label, in the case that skosxl:Labels have to be unique for each concept (i.e. even when others with the same literalForm already exist)
>
> 2)SKOSXL development tools (such as http://vocbench.uniroma2.it/). Which sort of integrity checks (out of the owl reasoning) should be made while a skosxl:label is being created? Should different “modalities” be selectable, or is there a clear design rule/best practice?
>
> Cheers,
>
> Armando
>
> *From:*Johan De Smedt [mailto:johan.de-smedt@tenforce.com]
> *Sent:* Thursday, January 2, 2014 2:47 PM
> *To:* 'Armando Stellato'; public-esw-thes@w3.org
> *Subject:* RE: identity of SKOSXL labels
>
> Hi Armando,
>
> You may want to have a look at the SKOS reference - http://www.w3.org/TR/skos-reference/#xl
>
> In particular Section B.2.4.1 (and less relevant for your issue: B.3.4.2)
>
> Kind Regards,
>
> *Johan De Smedt *
>
> /Chief Technology Officer/
>
> //
>
> mail: johan.de-smedt@tenforce.com <mailto:johan.de-smedt@tenforce.com>
>
> mobile: +32 477 475934
>
> mail-TenForce
>
> *From:*Armando Stellato [mailto:stellato75@gmail.com] *On Behalf Of *Armando Stellato
> *Sent:* Thursday, 02 January, 2014 13:46
> *To:* public-esw-thes@w3.org <mailto:public-esw-thes@w3.org>
> *Subject:* identity of SKOSXL labels
>
> Dear all,
>
> suppose in SKOS I have:
>
> mythes:C1  skos:prefLabel “foo”
>
> mythes:C2  skos:altLabel “foo”
>
> In SKOSXL, should I have something like:
>
> mythes:C1  skosxl:prefLabel mythes:foo
>
> mythes:C2  skosxl:altLabel mythes:foo
>
> mythes:foo skosxl:literalForm “foo”
>
> or like this? :
>
> mythes:C1  skosxl:prefLabel mythes:foo_1
>
> mythes:C2  skosxl:altLabel mythes:foo_2
>
> mythes:foo_1 skosxl:literalForm “foo”
>
> mythes:foo_2 skosxl:literalForm “foo”
>
> in other words, is SKOSXL enforcing in any way that concepts which are expressed through same lexicals, should have in any case their own labels for them or, on the contrary, a same label should be used…or these is no indication about that?
>
> In http://www.w3.org/TR/skos-reference/skos-xl.htmlthere is no hint about that, but I almost recall that I read/heard somewhere that the skosxl reification of the labels is *not* meant to “unify” labels with identical literalForms under a same URI, thus the general rule is to use in any case a different label URI for each concept.
>
> Could anyone shed some light on this? (and, in case, point me to the appropriate link if there is any…)
>
> Cheers,
>
> Armando
>
> P.S: in the example, I put a prefLabel for C1  and an altLabel for C2, but assuming the specific properties being used do not affect the answer to my question, so it could be skos:***Label. Pls let me know if this matters anyhow.
>

Received on Thursday, 2 January 2014 20:39:18 UTC