Re: identity of SKOSXL labels

Hello Armando,

Sorry for having missed the other part of your question.

I'm afraid I can't give you a complete answer however: to some extent it depends on the nature of the knowledge/lexical system you want to represent in SKOS.

Imagine "foo" is the label you want to link to C1 and C2. Can this label get a different set of attributes, when it is linked to C1 or C2? If not, then creating and re-using one same URI (ex:foo) makes sense. Otherwise, if you think "foo" may get different properties depending on its context of use, then you must create two uris ex:foo-C1 and ex:foo-C2.

I'm sorry not to give a more precise answer. The truth is, that at the time we thought of SKOS-XL constraints, we foresaw both kinds of scenarios, and one did not seem more legitimate for us to enforce/support it.

Best,

Antoine

On 1/4/14 2:57 AM, Armando Stellato wrote:
> Dear Antoine,
>
> thanks a lot for the detailed background on it, it is really appreciated, as I get more of the design principles behind SKOS/SKOSXL.
> However - and I hope not to be annoying - this clarifies things on one side (the "what if" with existing labels), while still leaving some doubt on the other (how to create labels).
>
> What I am asking is, with reference to the examples I made in my first email:
> If I have to create skosxl:labels for concepts C1 and C2 (with identical literal form "foo"), and if I'm willing to use URIs (not bnodes), should I create them with *different* URIs? (is SKOSXL enforcing this? Is it a best practice? Is it suggested but not mandatory?).
>
> The "identity is not guaranteed" statement with respect to skosxl:labels with identical literalForms is clear to me, but formally, it does not entail an answer to my question above (because it may hold to be true for very different answers to that question).
>
> Many thanks,
>
> Armando
>
>> -----Original Message-----
>> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
>> Sent: Thursday, January 2, 2014 9:39 PM
>> To: public-esw-thes@w3.org
>> Subject: 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 Saturday, 4 January 2014 09:40:52 UTC