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

Joseph Tennis wrote:

>> <skos:Concept rdf:about="uri">
>>   <!-- definition of the concept -->
>> </skos:Concept>
>>
>> <skos:Concept rdf:about="uri">
>>   <!-- changes related to the concept -->
>> </skos:Concept>
>>
>> both skos:Concept could be in the same resource or different
>> resources and RDF will piece the information together.
> 
> Exactly.  We're interested and worried about the creation of new URIs
> where there need be only one.  How would one piece together that
> information?

With mappings between the versions.

>> For the deprecated concept issue, if we have a URI like,
>>
>> <http://dewey.oclc.org/123.45>
> 
> This in my mind is a label, not a concept.  Am I wrong to consider this
> a label?

No, it looks like an URI. The label may be "123.45" and the URI should
better include an edition number, for instance

<http://dewey.oclc.org/22/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.
> 
> Right!  So we need to separate out labels from concepts.  
> SKOS does this yes?

Labels and concept do not have to be seperated. In the example above
there are (with number "XXX.XXX")

<http://dewey.oclc.org/19/XXX.XXX> skos:altLabel@en "peaches"
<http://dewey.oclc.org/19/XXX.XXX> skos:prefLabel@art "XXX.XXX"

<http://dewey.oclc.org/20/XXX.XXX> skos:altLabel@en "peaches"
<http://dewey.oclc.org/20/XXX.XXX> skos:prefLabel@art "XXX.XXX"

<http://dewey.oclc.org/21/XXX.XXX> skos:altLabel@en "peaches"
<http://dewey.oclc.org/21/XXX.XXX> skos:prefLabel@art "XXX.XXX"

The only information that cannnot be expressed in SKOS yet is that a
Concept is deprecated - for instance we could use a new class
skos:DeprecatedConcept:

<http://dewey.oclc.org/19/XXX.XXX> rdfs:type skos:Concept
<http://dewey.oclc.org/19/XXX.XXX> rdfs:type skos:DeprecatedConcept
<http://dewey.oclc.org/21/XXX.XXX> rdfs:type skos:Concept

If XXX.XXX was reused for apples in edition 21 there should be no
overlap between the class in edition 22, 20 and 19 so no mapping needs
to be specified - so no mixing up of information for the concepts in
edition 19 and 21 because the concepts have nothing in common but their
notation.

>> 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.
> 
> This ties scheme to concept which goes against SKOS modeling yes?  

No.

* First a scheme in SKOS is just a set of concepts and a concept can
belong to as many schemes as you like, for instance DDC edition 21, your
local DDC subset scheme, my private KOS that includes some DDC classes etc.

* And second the URI has no semantic meaning -
http://dewey.oclc.org/21/123.456> may look like the URI for DDC number
123.456 in edition 21 but unless you specify this with RDF it could be
an URI for anything. Including information in URIs just helps managing
them - you could also just assign consecutive number for every concept
you create with absoluly no difference in meaning.

Greetings,
Jakob

Received on Monday, 4 September 2006 07:30:14 UTC