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

Joseph Tennis wrote:

>> 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.
> 
> Exactly.  The URI should be meaningful :-)  That was my point in
> bringing up this issue.

Of course you can encode information in the URI, for instance a notation
or version number. But this does not make the URI meaningful - it only
makes it mnemonic.

>>> 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.
> 
> We're modeling any scheme submitted to the registry.

So people can submit schemes to the registry that include concepts that
are also used in other schemes? Is that the reason for a need for change
notes connected to 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.
> 
> So tell me more about this superconcept CAT and cat1 and cat2... it
> sounds an awful lot like my Concept vs. ConceptInstance.

Everything is a Concept:

CAT  rdfs:type skos:Concept
cat1 rdfs:type skos:Concept
cat2 rdfs:type skos:Concept
..

Some concepts are related to each other:

CAT  skos:broader  cat1
cat1 skos:narrower CAT
CAT  skos:broader  cat2
cat2 skos:narrower CAT
..

or

CAT  map:broadMatch  cat1
cat1 map:narrowMatch CAT
CAT  map:broadMatch  cat2
cat2 map:narrowMatch CAT
..

That's all. No need for ConceptInstance.


>> 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.
> 
> Safe side of what?  What do I achieve if I use SKOS Mapping?  How do I
> reflect meaningful change with majorMatch, for instance?

Safe side of compatibility for the future. skos mapping may change but
broadMatch, exactMatch, majorMatch, minorMatch, and narrowMatch will
probably stay. AND/NOT/OR should be merged with coordination because
it's not a mapping issue. That's why I would only bet on broadMatch,
exactMatch, majorMatch, minorMatch, and narrowMatch to stay.

>>> 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.
> 
> I'm sure this is obvious to you, but it puzzles me.  Please tell me how
> you get percentages without numbers.

Guessing? It's way easier to tell "Well, half of the records will fit in
this concept but the other half needs another concept to index" than
"well, we'll have 20 records here and 15 there". To map KOS there are
two fundamental methods:

* statistical (based on the number of records)
* intellectual (based on thinking about and comparing the meaning)

If you create a new version of a concept you have to think about it
anyway so you should be able to judge how it maps to your old version.
If you're not able to tell what the concept is about and why you created
a new version then you should better not introduce it.

>> Furthermore you won't specify a new version of a concept
>> without any idea how this concept should be used for indexing.
> 
> You may have the idea, but you don't have the resources.  And resources
> are what define exactMatch, majorMatch etc.  SKOS Mapping doesn't work
> for versioning.

It does not make *any* sense to create a KOS without having in mind the
records you want to index with it (at least if you don't believe in
Platonic realism).

>> 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
> 
> Seems to throw away some semantics here, and seems to be blithely
> ignorant of consistency issues and prediction of application in the
> networked environment.  It's like trying to comb your hair with a coffee
> cup.  It'll work, but it wasn't designed for the job.

Yes, struggling with reality is just like trying to comb your hair with
a coffee cup. As long as you want to model real world issues with SKOS
you will always have to deal with it - that's life. I suggest to read
"The Search for the Perfect Language" by Umberto Eco - it's very
amusing and instructive.

Greetings,
Jakob

Received on Tuesday, 5 September 2006 07:25:33 UTC