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

Joseph Tennis wrote:

>>> 2. This means that a concept can exist in many schemes (further
>>> demonstrated by SKOS's inScheme)
>>> 3. However, each scheme delimits the meaning of a concept by
>>> its relationships with other concepts in the scheme.
>>
>> 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).
> 
> It is both philosophical and practical in my mind.  You have pointed to
> one component of the problem (objectivistic approaches versus
> subjectivistic approaches), but I would argue that usage is linked to
> relations in indexing practice - which is the point of many (if not
> most) of the schemes we're concerned with in SKOS.
> 
> Your binary of either it is or is not the same thing goes against the
> SKOS Mapping system yet?  I assumed that if we can map between schemes
> and have imperfect matches then there is some fuzziness there.  That
> is, it's not just a binary result (i.e., same or not same).

My binary of either or is only about using the same URI or not. If you
have imperfect matches between two concepts A and B then A and B are
binary different (different URIs) but you should specify a mapping. If
you have a perfect match you can either use the same concept A and skip
B (binary the same) or create a new concept B (binary different) and an
exactMatch between A and B.

>>> 4. Change notes, as properties of concepts, are not linked to the scheme
>>> in which the change applies.
>>
>> Because they are independent from Schemes.
> 
> Here is where we have identified our needs.  We need Change notes that
> are not independent of Schemes.

How many schemes do you deal with? If your always use a concept in one
scheme than it does not matter that the change note is only connected to
the concept. Other people that may reuse your concepts in their schemes
should also be interested in you change notes.

>>> 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.
> 
> If we do this, then we're stuck with many many many many uri's for 'cat'
> for example, because we conceptualize cat in different ways in different
> schemes.  Here you can see, again, my bias to understanding an instance
> of a concept in context (in a Scheme).

Yes, that's exactely the purpose of SKOS and RDF: We want to create
many, many, many URIs for 'cat' for example for each different
reasonable conceptualization of cats that's in use. If you conceptualize
a thing in different ways that it's either *not* the same thing or your
differences are not relevant enough for you application and you have to
ignore them - that's what I meant with binary.

Of course you can create a superconcept CAT that's conected to narrower
concepts cat1, cat2 etc. or you can specify mappings between cat1,
cat2... - but then you will have more URIs.

>> Why don't you use skos:broader, skos:narrower, skos:related or
>> mapping:broadMatch, mapping:exactMatch, mapping:majorMatch,
>> mapping:majorMatch, mapping:narrowMatch depending on how the concept
>> changed? Introducing a totally new ConceptInstance does not look very
>> consistent.
> 
> Using SKOS Mapping for our purposes is problematic on a number of
> fronts.  First, if we take your binary, then many tools in the SKOS
> Mapping don't work. 

With the "binary" you took me wrong, see above, but the issue of tools
may be a problem because skos mapping is not finished yet so there are
no tools - but if you just use broadMatch, exactMatch, majorMatch,
minorMatch and narroMatch without the complex AND/NOT/OR-stuff you
should be on the save side.

> Second, Mapping is based on # of resources assigned
> a particular concept (i.e., defined by usage after indexing), this won't
> work for our needs if we issue a new version - because there are no
> resources attached to the new version.

That's not exactely true. Mapping is based on percentage and not on
numbers. Furthermore you won't specify a new version of a concept
without any idea how this concept should be used for indexing. Let C1 be
a concept in version 1 and C2 in version 2 so just ask yourself:

* Will more or less the same resources be indexed with C2 that were
indexed with C1 before? => then it's exactMatch

* Will same resources be indexed with C2 that were indexed with C1
before but also other resources that would not have been indexed with C1
before? => then it's broadMatch

etc.

Greetings,
Jakob

Received on Monday, 4 September 2006 07:57:22 UTC