W3C home > Mailing lists > Public > public-esw-thes@w3.org > August 2006

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

From: Aida Slavic <aida@acorweb.net>
Date: Tue, 29 Aug 2006 13:13:39 +0100
To: "Jakob Voss" <jakob.voss@gbv.de>, <public-esw-thes@w3.org>
Message-ID: <JMEIJBPGGHDKPALMMJDFGEABCGAA.aida@acorweb.net>

Jakob,
having in mind the time difference with America I suppose you will have to
wait for Joe's answer to this.

>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


>> 4. Change notes, as properties of concepts, are not linked to the scheme
>> in which the change applies.
>Because they are independent from Schemes.

if there is anything scheme specific - these must be the notes.
They are used to interpret the meaning, scope and use of the term within the
specific scheme.

>> 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.
This is very relevant for both mature systems and for those being in the
process of development. Just the other day, for instance
I was checking the new proposal for the
extensions of vocabulary of mathematics (UDC).
One of the problems I noticed was the change of class descriptions next to
the
existing classes  - the change was qualified by the author as a 'text
change'.
Sometimes this would be only a slight changes in the scope but in some cases
it was
actually a new concept and there is a strict policy how to deal with this
not to
disturb the permanency/continuity of a vocabulary as implemented in
practice.

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.
(Vocabulary editorial systems usually have historical/revision note for
changes and keep
cancelled concepts as a part of the system with instruction for their
replacement  (replaced by ->))
In UDC cancellations, additions and changes of the scheme are also
distributed to users as separate files
every year (e.g. cancellation file (text export, short version) is at
http://www.udcc.org/cancellations.htm.
Am I wrong in assuming that in a scenario related to SKOS (or terminological
services)
these data would be kept all together?

aida

P.S. I read somewhere (ages ago) about Dewey's consideration to tie the
concept ID with a scheme edition
and notation through a structured URI (name of the scheme/edition/notation).
This essentially means a different URI for the same
concept (with or without some changes in text or scope). I don't know how
this
approach would help an automatic update of the scheme in the users authority
files or track changed/cancelled
classes. I am not sure the proposed suggestion is still valid though.
Received on Tuesday, 29 August 2006 12:14:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:54 GMT