Re: Failing to meet integrity constraint S14 when terminology evolves

Dear Antoine,

I fully agree with what you stated 
[
I reckon all these are not "simple" solutions anymore. But somehow you 
must realize that your requirements do not seem to be simple, either!
]

This specific terminology system  am working on, namely ICD10GM, is a 
classification vocabulary, it does not add or delete semantic 
relationships in purpose in releasing a new version. However, when a 
concept is added or deleted, it does add or remove semantic relationships 
implicitly. This might be an additional problem which I did not consider 
previously. Nevertheless, I deem this would not be a big problem for this 
particular terminology system, but might bring big impact on other 
terminology systems.

Thank you very much for providing the nice references! In some of the 
referenced solutions, e.g. formalizing a concept as below,

<http://zbw.eu/stw/descriptor/10112-4>
skos:prefLabel "Welfare analysis"@en , "Wohlfahrtsanalyse"@de ;
:history [ :altLabelDeltion "Wohlfahrtsmessung"@de , "Wohlfahrtsmaß"@de , 
"Welfare measurement"@en , "Wohlstandsmaß"@de ;
:altLabelInsertion "Welfare effect"@en , "Wohlfahrtsgewinn"@de , 
"Wohlfahrtseffekt"@de , "Wohlfahrtsverlust"@de ;
:delta <http://zbw.eu/stw/version/8.08/delta/8.10> ;
:prefLabelDeletion "Welfare effect"@en , "Wohlfahrtseffekt"@de ;
:prefLabelInsertion "Wohlfahrtsanalyse"@de , "Welfare analysis"@en
] .

I found there is still potential conflicts when snapshots of  different 
versions are merged together. E.g. it appears that in version8.08, 
prefLabel is
<http://zbw.eu/stw/descriptor/10112-4> skos:prefLabel  "Welfare effect"@en 
, "Wohlfahrtseffekt"@de ;
while in version 8.10, the preflabel is
<http://zbw.eu/stw/descriptor/10112-4> skos:prefLabel "Welfare 
analysis"@en , "Wohlfahrtsanalyse"@de ;

Nevertheless, I agree with you that this is a complex issue and myself 
also didn't find a clean solution, and might in the end take a solution 
similar to the example above, with the known potential conflicts, as Osma 
and Christian also suggested.

kind regards,
Hong




From:   Antoine Isaac <aisaac@few.vu.nl>
To:     <public-esw-thes@w3.org>
Date:   11/15/2013 06:40 PM
Subject:        Re: Failing to meet integrity constraint S14 when 
terminology evolves



Dear Hong,

On using skos-xl. If you want to old label to be a xl:literalForm of the 
same resource as the "new label", it won't fly, indeed.
What you should do is to create a new instance of xl:Label (with its 
unique xl:literalForm set as the old label), and maybe use a property to 
link it to the instance that represents the new label.

But I would really prefer to focus on this:
[
Skosify could help to resolve local conflicts, however, it can not solve 
the conflicts of the published facts on the web (Because it does not have 
the right to drop the published fact icd10gm:K12.23 skos:prefLabel 
"Wangenabszess"@de.). Such conflicts to the published facts is what I 
considered as a problem.
]

This is I believe *the* problem. In fact you experience it currently via a 
very specific angle (label data), but I believe that your new versions 
could also include addition or removal of semantic relationships, no?
And such case demonstrate clearly what the limits of trying to shoehorn 
every version's data on one single resource, without specific mechanisms.

A more appropriate handling of versions would indeed need either to create 
"shades/versions" of concepts (as in ISO25964 [1] [2] or [3] or to turn to 
general data provenance mechanisms like named graphs (which can result in 
conflicts for tools that can't handle them, especially regarding the 
uniqueness of skos:prefLabel).

The issue of representing versions in a "clean" way has been approached 
several times, see previous refs and [4]
I reckon all these are not "simple" solutions anymore. But somehow you 
must realize that your requirements do not seem to be simple, either!

Best,

Antoine

[1] http://www.niso.org/schemas/iso25964/correspondencesSKOS/ (last part 
of the document)
[2] 
https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2009/presentations/slavic_isaac_NKOS2009_06.pdf

[3] http://dcevents.dublincore.org/IntConf/dc-2013/paper/view/152/168 also 
discussion at 
http://lists.w3.org/Archives/Public/public-esw-thes/2013Sep/thread.html
[3] http://www.w3.org/2001/sw/wiki/SKOS/Issues/ConceptEvolution


> Thanks Christian!
>
> I tried to use skosxl:prefLabel and assign multiple skosxl:literalForm 
in case multiple labels exist.
> Unfortunately, I found there is a restriction preventing me to do so:
> 'restriction on skosxl:literalForm cardinality exactly 1'
> I then find the problem I experienced in SKOS also exist with SKOS-XL, 
or do you have better ideas in formalizing the case with SKOS-XL?
>
> best regards,
> Hong
>
>
>
>
> From: Christian Mader <mail@christianmader.net>
> To: Hong Sun/AXIFX/AGFA@AGFA
> Cc: <public-esw-thes@w3.org>
> Date: 11/13/2013 10:05 AM
> Subject: Re: Failing to meet integrity constraint S14 when terminology 
evolves
> 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>   Hi Hong,
>
> Maybe you could take a look at the SKOS-XL schema [1] which allows you
> to express your labels not only as text literals but as owl classes. You
> can then add history/versioning information to these label resources.
>
> [1] http://www.w3.org/TR/skos-reference/skos-xl.html
>
> best,
> Christian
>
> Am Dienstag, den 12.11.2013, 18:13 +0100 schrieb Hong Sun
> <hong.sun@agfa.com>:
>  > Dear All,
>  >
>  > I have a problem in assigning labels to SKOS concepts within an
>  > evolving terminology, and am therefore looking for your opinions.
>  >
>  > In the ICD 10 coding system, Germany version, the text assigned to a
>  > code changes between different versions, e.g.
>  > in ICD10GM 2004, the code K12.23 has a label:Wangenabszeß
>  > in ICD10GM 2013, the code K12.23 has a label:Wangenabszess
>  >
>  > Before realizing the problem, I formalized the code as SKOS concept:
>  > icd10gm:K12.23 a skos:concept;
>  >  skos:prefLabel "Wangenabszeß"@de.
>  > However, it ends up with
>  > icd10gm:K12.23 a skos:concept;
>  >  skos:prefLabel "Wangenabszeß"@de;
>  >  skos:prefLabel "Wangenabszess"@de.
>  > which is not consistent with the integrity constraint S14.
>  >
>  > As the ICD 10 GM publish a new version each year, and most of the
>  > labels are stable, it also seems to be overkill to create a concept
>  > for each version, e.g.
>  > icd10gm2004:K12.23 a skos:concept;
>  >  skos:prefLabel "Wangenabszeß"@de.
>  > and
>  > icd10gm2013:K12.23 a skos:concept;
>  >  skos:prefLabel "Wangenabszess"@de.
>  >
>  > I also consider to take the labels from the latest version as
>  > prefLabel, and those from an older version as altLabel, e.g.
>  > icd10gm:K12.23 a skos:concept;
>  >  skos:prefLabel "Wangenabszess"@de;
>  >  skos:altLabel "Wangenabszeß"@de.
>  >
>  > The problem for this approach is that in case the code changes in
>  > later versions(e.g. v2014), then the skos:prefLabel needs to be
>  > updated again. If the formalized terminology is already published,
>  > then such request to update will be a problem.
>  >
>  > I currently planed to formalize the concept as below:
>  > icd10gm:K12.23 a skos:concept;
>  >  rdfs:label "Wangenabszess"@de;
>  >  rdfs:label "Wangenabszeß"@de.
>  >
>  > Still not very satisfied with this solution yet. Is there any better
>  > solution with other SKOS properties? Meanwhile, is there a general
>  > principle/guideline for SKOS in formalizing (the labels) of an
>  > evolving terminology? Thanks!
>  >
>  >  Kind Regards,
>  >
>  >  Hong Sun | AGFA HEALTHCARE
>  >  Researcher | HE/Advanced Clinical Applications Research
>  >  T +32 3444 8108
>