- From: Joseph Tennis <jtennis@interchange.ubc.ca>
- Date: Mon, 04 Sep 2006 07:00:03 -0700
- To: SKOS <public-esw-thes@w3.org>
On 4-Sep-06, at 12:58 AM, Jakob Voss wrote: > > 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. Exactly. The URI should be meaningful :-) That was my point in bringing up this issue. > >>>> 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. We're modeling any scheme submitted to the registry. > >>>> 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. So tell me more about this superconcept CAT and cat1 and cat2... it sounds an awful lot like my Concept vs. ConceptInstance. > >>> 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. Safe side of what? What do I achieve if I use SKOS Mapping? How do I reflect meaningful change with majorMatch, for instance? > >> 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. > 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. > 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. I believe we've identified the problem, and the fact that SKOS and SKOS Mapping - as yet - do not allow for satisfactory solutions to the problem. Thank you for thinking about this, joe > etc. > > Greetings, > Jakob > 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 Monday, 4 September 2006 14:00:30 UTC