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

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

From: Svensson, Lars <l.svensson@d-nb.de>
Date: Wed, 30 Aug 2006 08:01:54 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA1972984038AEFF6@dbf-ex.AD.DDB.DE>
To: "Houghton,Andrew" <houghtoa@oclc.org>, <public-esw-thes@w3.org>

In litteris suis de Dienstag, 29. August 2006 15:07,
public-esw-thes-request@w3.org <>scripsit:


>> 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.
> I probably wrote that and it is still a concern with SKOS/RDF
> in regard to Dewey and possible other vocabularies.  There are
> multiple issues around identifiers for Dewey which essentially
> has put our SKOS work on hold.
> One of the issues that Dewey faces has to do with concepts
> being deprecated in one edition and reused in another edition
> for a different concept.
Are really the *concepts* being reused or only their notations? If it's
the same concept, it schouldn't be a problem, but the point is, that the
same notation is being used for a different concept.

> Another issue has to do with options
> allowed by the classification.
> For the deprecated concept issue, if we have a URI like,
> <http://dewey.oclc.org/123.45>
> that points to the concept peaches in Edition 19 and that
> concept is deprecated in Edition 20, but then reused in
> Edition 21 for apples, then we perceive a serious problem,
> based upon our limited knowledge of RDF.  RDF would take both
> those skos:Concept elements and merge them together.  Thus,
> mixing up the information for the concepts in Edition 19 and 21.
> To solve this issue we proposed using a URI that included
> scheme, edition, translation, and notation.
I remember that we discussed this together with Diane in some time ago
(October 2004?). We considered at that time to use the query part of the
URI to denote the language, but now I'd say that the language is
irrelevant and a URI like http://dewey.oclc.org/22/123.45 (or maybe
http://dewey.oclc.org/22#123.45) ought to do fine. The problem, of
course, is when we don't know which edition is used, but in that case we
could map http://dewey.oclc.org/#025.431 to
http://dewey.oclc.org/<currentEdition>#025.431 (which would have to be
updated with each new edition).

> It would keep the
> skos:Concept elements from being merged by RDF.  To track
> relationships of concepts between editions we thought that we
> could use OWL or use the SKOS mapping vocabulary.
Yup, that's what I'd say, too. This way the relocations (where a concept
is moved to another part of the schedule betwen editions) can be
handled, too. It might be, however, that neither owl:sameAs nor
skosmap:exactMatch fits the bill. owl:sameAs would allow a reasoner to
merge all properties anyhow, and to me skosmap:exactMatch somehow
implies that they are different concepts having a perfect match rather
than being the same concept. I might be wrong.
> For the options allowed issue, it's a similar problem but
> instead of deprecated concepts we are dealing with relocated
> concepts.  An example of this appears in the religion
> schedule.  Many would say that Dewey's religion schedule is
> biased toward Christianity.  An option exists where you can
> relocate the numbers in the religion schedule.  This option is
> used in the Arabic edition where Islam is the predominate
> religion and not Christianity.  So the concept identifier
> 234.56 in the English edition of Dewey could mean something
> totally different in the Arabic edition.
So we would need a different URI for concepts taken from the options.
Something like http://dewey.oclc.org/22#234.56?optionUsed=A to signal
that it's different from the standard 234.56. Here we could use
owl:sameAs to signal that it's really the same concept:

@prefix ddc22 http://dewey.oclc.org/22# .
ddc:234.56?optionUsed=A owl:sameAs ddc:256.34 .

(or whatever).
> How these issues can be properly managed with SKOS, RDF, OWL
> and URI we are still trying to figure out.  We are not RDF or
> OWL experts which complicates matters.  If anyone on the list
> has any ideas on URI's for Dewey in SKOS, pros or cons about
> what I discussed above, please feel free to contact me
> off-list.  We are very interested in hearing a diversity of
> opinions, to help us formulate a direction.
I'd like to catch up where we left two years ago. I'll get back to you.


Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Adickesallee 1
60322 Frankfurt
Received on Wednesday, 30 August 2006 06:02:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:33 UTC