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

Hi Jakob:


On 29-Aug-06, at 2:27 AM, Jakob Voss wrote:

>
> Dear Joseph Tennis,
>
> I can only give some naive comments - maybe they help.
>
>> Hello.  I, along with Stuart Sutton, have started to model changes in
>> schemes using SKOS.  We want to keep track of changes within and  
>> between
>> versions of schemes.  However, we've run into a problem.  The  
>> problem is:
>>
>> 1. SKOS postulates a concept exists independent of a scheme
>
> That's also general in the Semantic Web as far as I understand.
>
>> 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).

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

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

>
>> You can see an illustration of the problem at:
>> http://www.ischool.washington.edu/sasutton/skos/ 
>> Concept_History_New.html
>>
>> You can also see how we are trying to solve the problem: by  
>> introducing
>> an ConceptInstance as well as a Concept.  This too can be seen at the
>> above URL.
>>
>> We are writing to ask this group to vet this idea.  We want to  
>> know, in
>> your opinions, what are the ramifications of this re-model.
>
> 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.  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.

>
> Greetings,
> Jakob
>

Thanks for thinking about this and contributing.
joe





Joseph T. Tennis, PhD
Assistant Professor
Coordinator for the MAS and MLIS First Nations Concentration
School of Library, Archival and Information Studies
The University of British Columbia
301 - 6190 Agronomy Road
Vancouver, BC V6T 1Z3
CANADA
phone: 1.604.822.2431
fax: 1.604.822.6006
jtennis@interchange.ubc.ca
http://www.slais.ubc.ca/PEOPLE/faculty/tennis-p/index.htm

Received on Friday, 1 September 2006 16:23:25 UTC