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

Hi Jakob:


On 29-Aug-06, at 10:12 AM, Jakob Voss wrote:

>
> 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

Right!  So we want to know what the considerations are in "mapping"  
these issues.

>
> 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"
>

Again, Mapping and exactMatch etc. only work when you've got % of  
cross over of resources between schemes.  It doesn't work for  
versioning.

>
> Do I miss something because I don't see the problem?
>
> Greetings,
> Jakob
>

Thanks for thinking about this!
joe



Joseph T. Tennis, PhD
Assistant Professor
Coordinator for the MAS and MLIS First Nations Concentration
School of Library, Archival and Information Studies
The University of British Columbia
301 - 6190 Agronomy Road
Vancouver, BC V6T 1Z3
CANADA
phone: 1.604.822.2431
fax: 1.604.822.6006
jtennis@interchange.ubc.ca
http://www.slais.ubc.ca/PEOPLE/faculty/tennis-p/index.htm

Received on Friday, 1 September 2006 16:35:24 UTC