Re: Modeling change in and between schemes using SKOS - the problem of persistent URIs

Aida Slavic wrote:

>> This is a rather philosophical question. The meaning of a concept is its
>> usage (subjectivism) or its inherent meaning (objectivism) but it does
>> not depend on which relations are known in which scheme. If a concept is
>> in two schemes than its either the same (same meaning) or not (different
>> concept).
> 
> I always thought this to be very practical issue :-) Most of KOS are created
> for specific purposes for specific field of knowledge
> and are not made to work as general ontologies
> 
> the concept of e.g. education will not have the same BT/NT/RT  or scope in
> a) thesaurus of education or social sciences
> b) thesaurus of religion
> c) thesaurus of library and information science
> 
> also the concept of e.g. marriage in
> a) thesaurus of sociology
> b) thesaurus of ethnography
> c) thesaurus of law
> d) thesaurus of religion

There is no concept of "education" or "marriage" - these are only words.
If you want to use a identifyable concept for marriage in the sense of
semantic web in two thesauri you have to decide whether it is the same
concept or not - there is nothing between. The same concept will have
*all* BT/NT/RT and scope notes of all Schemes that it is used - if you
use the same URI. If you better like to model different concepts for
different schemes then they are totally different for dull computers no
matter if they have the same prefLabel or not - unless you specify a
relation like mapping:majorMatch.

>>> 5. We are left to ask: how do we model scheme specific changes to
>>> concepts without signaling a new URI?
>> You have to judge if the change is relevant enough to introduce a new
>> concept are just use the same concept.
> 
> glad to agree about something!
>
> This has nothing to do with SKOS but rather with a strict policy in the
> maintenance of the scheme which regulates when the cancellation of the 
> old and the introduction of a new concept is justified.

I assume the solution to the problem raised by Joseph is less in
brilliant encoding but more in enforcing a strict usage policy. People
will always find a way to bypass your system ;-)

> But the problem, I think, Joe talks about is the need to keep together
> information about cancelled/changed concepts in the same scheme - since 
> the development of the scheme itself is usually separate from its
> implementation. E.g. although concept is cancelled or changed the old
> record of it and the history of its changes has to exist for both
> editors and users.

I don't see why this should not work with
a) unique URIs for each concept and version of a scheme
b) mappings between the versions of a scheme

We only need a way to indicate that a concept is deprecated in a given
Scheme. For instance skos:deprecatedConcept

Here is an example: A Scheme contains

* In version 1 the concepts A, B, C

This is version 1:

skos:Concept A has URI "v1-A"
skos:Concept B has URI "v1-B"
skos:Concept C has URI "v1-C"

* In version 2 the concepts A, B (same meaning) and C where the meaning
of C has slightly changed

This is version 2:

skos:Concept A has URI "v2-A"
skos:Concept B has URI "v2-B"
skos:Concept C has URI "v2-C"

There is a relation "v1-A map:exactMatch v2-A"
There is a relation "v1-B map:exactMatch v2-B"
There is a relation "v1-B map:majorMatch v2-C"

* In version 3 the concepts A (same meaning) and C (same meaning), B is
dropped

This is version 3:

skos:Concept A has URI "v3-A"
skos:deprecatedConcept B has URI "v3-B"
skos:Concept C has URI "v3-C"

There is a relation "v3-A exactMatch v2-A"
There is a relation "v3-B exactMatch v2-B"
There is a relation "v3-C exactMatch v2-C"


Do I miss something because I don't see the problem?

Greetings,
Jakob

Received on Tuesday, 29 August 2006 17:11:54 UTC