W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2004

RE: candidate and deprecated concepts

From: Carl Mattocks <carlmattocks@checkmi.com>
Date: Sat, 9 Oct 2004 11:41:15 -0400 (EDT)
Message-ID: <1348.68.37.145.1.1097336475.squirrel@webmail.netcarrier.com>
To: "Charles McCathieNevile" <charles@w3.org>
Cc: "Carl Mattocks" <carlmattocks@checkmi.com>, "Stella Dextre Clarke" <sdclarke@lukehouse.demon.co.uk>, "'Miles,\ AJ \(Alistair\) '" <a.j.miles@rl.ac.uk>, "'Leonard Will'" <l.will@willpowerinfo.co.uk>, public-esw-thes@w3.org

Chaals :

Clarification accepted with thanks .. but requesting more on the 'forwards
/ backwards compatible lumping'
(1) within a single thesaurus
 - same set of author(s) / steward(s) thus same purpose
(2) a different thesaurus .
- different (single) set of author(s) / steward(s) different purpose


<quote who="Charles McCathieNevile">
> Trying to clarify:

> It is reasonably easy to say that some parts of a thesaurus are
> forwards/backwards compatible with some other parts of a different
> thesaurus.
> For example a new thesaurus that lumps bananas and mangoes together isn't
> backwards compatible with an original one that identifies them, unless
> there
> is a concept for the lumping together in the original. But the original is
> forwards compatible with the new one since you don't lose anything (in the
> context of what the new thesaurus tells you) by using its interpretation.
>
> (Al and I wrote some stuff up about how to do this. The code looks ugly,
> because its designed to work across the open environment of the semantic
> web,
> but it's actually pretty simple in practice - the diagrams would be much
> cleaner :-)

Please forward the diagrams


> If you deprecate a term, you just make it a non-preferred and make a new
> preferred term. You might want to make a "deprecatedPreferred" as a
> subproperty of altLabel (or whatever it's called), and you might want to
> be
> able to note the date when something was deprecated (in which case you
> need
> to be able to use an anonymous node in modelling it, not just a literal,
> but
> the mechanics boil down to putting a date in the right place). This means
> you
> can compare usage with what applied at the time - an important check on
> quality control, since people using the right thing at the right time is
> different from people not noticing something has changed.

absolutey in agreement


cheers
carl

> On Fri, 8 Oct 2004, Carl Mattocks wrote:
>>
>>Since I also believe this type of 'concept evolution' information is
>>valuable .. for discussion purposes I propose we use -
>>the notion of UseVersioned (that includes start & end time when version
>>was current) to identify when a particular 'Thesaurus Concept' is (was)
>>the preferred 'term' for indexing and /or query purposes;
>>the notion of BroaderTermSuperceded to identify when the conceptual
>>framing (the collection of narrower terms) has been modified.
>>
>><quote who="Stella Dextre Clarke">
>>>
>>> No time to explore this in detail. But there is a grey area in the
>>> definition of "concept", concerning broad concepts and narrow concepts.
>>> The concept of Tropical products is quite a broad one, broader than
>>> Tropical fruits and much broader than Bananas. So in one sense it holds
>>> all those narrower concepts within it, and the broader term becomes the
>>> preferred term for those narrower concepts. In this sense, the narrower
>>> concepts are still there, whether or not their presence is revealed by
>>> providing a non-preferred term. Another way to look at it is to say No,
>>> you should use Tropical products only in the context of queries or
>>> documents that deal with the subject broadly. And when narrower
>>> preferred terms are present, that is what we do say. But when the
>>> narrower terms are non-preferred, pointing to the broader one, we
>>> usually allow that broader term to be used for all the narrower
>>> concepts
>>> within its scope.
>>>
>>>
>>>> It is unusual to drop a concept altogether.
>>>> Normally one
>>>> provides a lead-in entry pointing to the broader concept that
>>>> covers the
>>>> scope of the preferred term that is now to be "deprecated".
>>>
>>> ... but this *is* to drop a concept, and say 'now use this concept
>>> instead', surely?
>>>
>>>> Much more likely would be to decide that that subject area should be
>>>> indexed at a much shallower level of specificity. So, for example, in
>>>> a thesaurus for agricultural products, it might be decided that
>>>> tropical products should no longer be covered in detail. Where
>>>> previously you had
>>>> Bananas, Pineapples, Brazil nuts etc as preferred terms ( with a
>>>> hierarchy of BTs such as Tropical fruits all the way up to Tropical
>>>> products), you might leave just one term "Tropical products" to cover
>>>> all of these. In the thesaurus you would organise entries such as
>>>> "Bananas USE Tropical products" - perhaps hundreds of such
>>>> entries. Now
>>>> where is the "deprecated concept"?
>>>
>>> The 'deprecated concepts' are all of the concepts that where previously
>>> reified in the thesaurus by the presence of a preferred term which is
>>> no
>>> longer preferred.
>>>
>>> (I.e. Every preferred term in a thesaurus reifies a concept.
>>> Non-preferred terms expand upon and refine the meaning of a concept.
>>> If
>>> you change a term from preferred to non-preferred, you are essentially
>>> dropping a concept from the thesaurus.)
>>>
>>>> I don't warm, either, to the idea of a concept getting "replaced" by
>>>> another one, unless they are so close that you would treat the two as
>>>> quasi-synonymous. You are hardly going to replace Bananas with Washing
>>>
>>>> machines?
>>>
>>> But in the above example, you are suggesting that the concept with
>>> prefLabel 'Bananas' should be replaced (in indexing metadata) by the
>>> concept with prefLabel 'Tropical products'.
>>>
>>>> So the idea of a "deprecated concept" just feels a bit alien.
>>>
>>> I am sensitive to this.  I'm just looking to find a way to model and to
>>> represent (in RDF) at least some of the features of the change process
>>> ... I have the idea that this information explicitly captured would be
>>> valuable.
>>>
>>> Al.
>>>
>>>>
>>>> Stella
>>>>
>>>> *****************************************************
>>>>
>>>>
>>>> I'm actually thinking about supporting candidate/deprecated *concepts*
>>>
>>>> (and not terms), which brings a slightly different set of
>>>> requirements.
>>>>
>>>> Al.
>>>>

>>>> > >
>>>> > >The paradigm (as I understand it) in the thesaurus world is
>>>> > for terms (or
>>>> > >concepts) to go through three stages: candidate, accepted,
>>>> > deprecated (i.e.
>>>> > >replaced).
>>>> > >
>>>> > >We can use dcterms:replaces and dcterms:isReplacedBy to
>>>> > describe concept
>>>> > >replacements I think (although how to handle replacement
>>>> > with combinations
>>>> > >is uncertain yet).
>>>> >
>>>> > If use of a term is discontinued, it is good practice to retain it
>>>> > as a non-preferred term, with a USE pointer to the term or
>>>> combination of
>>>> > terms that should be used in future for the concept that it
>>>> > represented.
>>>> > A history note should indicate when it was used for indexing.
>>>> >
>>>> > I don't think that you need to distinguish between "deprecated" and
>>>> > "non-preferred" terms, which you would express as altLabels. As you
>>>> > have noted, you do however have to handle combinations such as:
>>>> >
>>>> > "physics education  USE  physics  AND  education"
>>>> >
>>>> > Leonard
-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi
Received on Saturday, 9 October 2004 15:41:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:04 UTC