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

Thanks for contributing to the discussion.

All the best,
joe

On 5-Sep-06, at 12:26 AM, Jakob Voss wrote:

>
> 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 13:18:03 UTC