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: Houghton,Andrew <houghtoa@oclc.org>
Date: Tue, 29 Aug 2006 09:06:47 -0400
Message-ID: <D53793AA582576458786FBE27899DB180273C777@OAEXCH2SERVER.oa.oclc.org>
To: <public-esw-thes@w3.org>

> From: public-esw-thes-request@w3.org 
> [mailto:public-esw-thes-request@w3.org] On Behalf Of Aida Slavic
> Sent: 29 August, 2006 08:14
> To: Jakob Voss; public-esw-thes@w3.org
> Subject: RE: Modeling change in and between schemes using 
> SKOS - the problem of persistent URIs
> 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?

Because SKOS is based on RDF, it would be wrong to assume that
the change data needs to be kept with the actual concept
information, e.g., scope notes.  You could have:

<skos:Concept rdf:about="uri">
  <!-- definition of the concept -->

<skos:Concept rdf:about="uri">
  <!-- changes related to the concept -->

both skos:Concept could be in the same resource or different
resources and RDF will piece the information together.

> 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.  Another issue has to do with options allowed
by the classification.

For the deprecated concept issue, if we have a URI like,


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

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.

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.


Andrew Houghton, OCLC Online Computer Library Center, Inc.
Received on Tuesday, 29 August 2006 13:07:08 UTC

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