RE: candidate and deprecated concepts

et Al:

I agree that 'Concepts never die'..
However, I am struggling with the statement that a concept is unstable
is this for a 'candidate' concept ?
is a slang word a 'candidate' concept ? and would it be in a thesaurus ?
are you referring to the term 'deprecated' ? :-} .

Addressing the question of how to note that a candidate/deprecated in one
scheme, but not in another...I agree with the proposal that SKOS allows a
'Thesaurus structure (BT-NT ) to be kept independent from the indexing
practices/applications ( USE-UF ) relationship that use the Thesaurus'.

n.b. I am also ok using the XTM subjectindicatorref

carl

<quote who="Miles, AJ (Alistair)">
>
>
>
>> Incidentally, a design question that arises (if there is
>> consensus that
>> making these kinds of statement is valuable) is how to
>> represent the fact
>> that a concept might be candidate/deprecated in one scheme, but not in
>> another.
>>
>
> Also, I think that describing the *stability* of a concept is disctinct
> from
> describing the *status of a concept wrt a specific scheme*.
>
> So I would like to be able to say (in RDF) both that:
>
> 'concept X is unstable'
>
> ... and ...
>
> 'concept X is a candidate in scheme Y'.
>> The *requirement for stability* dictates that, once a concept has been
> published, it should certainly never be deleted, and it should be altered
> as
> little as possible, ideally not at all.  If this practise is observed, one
> can to a large extent guarantee the appropriateness of indexing values
> over
> time.
>
> However, the *requirement for fitness* dictates that a concept scheme must
> be allowed to evolve to reflect changing patterns of usage, perspectives
> and
> systems of thought.
>
> I would like to be able to offer a recommendation as part of the SKOS Core
> guide that balances the tension between these two requirements.  So far,
> the
> best I can come up with is something like:
>
>   'whenever there is pressure to significantly alter the meaning of a
> concept or set of concepts, preference should be given to defining a new
> concept or set of concepts, with new unique identifers, and expressing
> mapping relationships between the old ('deprecated') concepts and the new
> concepts.'
> Here, 'deprecated' means 'do not use this concept'.  An 'isReplacedBy'
> statement means 'use this concept instead'.  A deprecated concept is
> allowed
> to persist, to support the backwards compatibility of older subject
> indexes.
>>
> Incidentally, a design question that arises (if there is consensus that
> making these kinds of statement is valuable) is how to represent the fact
> that a concept might be candidate/deprecated in one scheme, but not in
> another.
>
> Al.
>
>
>>
>> > -----Original Message-----
>> > From: public-esw-thes-request@w3.org
>> > [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
>> > Sent: 11 October 2004 10:06
>> > To: Stella Dextre Clarke; public-esw-thes@w3.org
>> > Subject: RE: candidate and deprecated concepts
>> >
>> >
>> >
>> >

>> > There again, only terms are replaced, not concepts.
>> >
>> > Bottom line : We need here to make distinct the *declarative*
>> > properties of concepts,
>> > valid whatever the context of application and the
>> > *procedural* properties, applicable only
>> > in specific contexts of use. For example seems to me that the
>> > BT-NT relationship between
>> > "Tropical Fruits" and "Bananas" should be declarative, and
>> > kept existing whatever the
>> > context, whereas the USE-UF relationship stated in order to
>> > use the Thesaurus at a broader
>> > level of granularity, is procedural: you know pretty well
>> > that "Tropical Fruits" and
>> > "Bananas" are distinct concepts, but in a certain context of
>> > application this distinction
>> > is useless for whatever reason. It's different from, say, you
>> > had an ancient astronomical
>> > thesaurus where "Evening Star" and "Morning Star" were
>> > thought as distinct concepts, and
>> > you decide/discover at some point that in fact they both have
>> > to be replaced by "Planet
>> > Venus". In this latter case, there is actually a
>> > (declarative) change in the conceptual
>> > scheme.
>> > It might be that the USE-UF relationship in Thesaurus is
>> > sometimes used in a declarative
>> > sense, and sometimes in a procedural sense, leading to some
>> > ambiguities.
>> > The above quoted notion of "index profile" allows to capture
>> > the procedural properties for
>> > various contexts, while not changing the declarative
>> > properties in the (common) Thesaurus.




<quote who="Miles, AJ (Alistair)">
>
> Bernard wrote:
>> Yes, there again, concepts never die. This is an important
>> rule I've found out in topic
>> map management : never delete a topic. Change its status,
>> attributes, names,
>> relationships, date of validity, but never delete. Once you
>> have spoken about something at
>> some point, this thing exists forever, at least as a subject
>> of conversation :))
>>
>
> Yes, I think this is absolutely crucial as a recommendation.
>
> N.B. this is why i tried to write about explicitly concept-oriented
> indexing: because if the subject-based index is built to take *concept
> identifers* and not terms as indexing values, then reshuffling which term
> is
> the preferred label for a concept is a minor issue.  It doesn't affect
> document metadata, and it can be adequately represented in RDF as a
> structured history note attached to a *concept*.  (i.e. I see no need to
> talk about 'deprecated terms').
>
> However, once we do have explicitly concept-oriented subject indexes,
> further change issues arise.
>

> Al.
>
>
>
>> -----Original Message-----
>> From: public-esw-thes-request@w3.org
>> [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
>> Sent: 11 October 2004 10:06
>> To: Stella Dextre Clarke; public-esw-thes@w3.org
>> Subject: RE: candidate and deprecated concepts
>>
>>
>>
>>
>> Stella
>>
>> > The difference between a deprecated concept and a
>> deprecated term may
>> > not be as clear as you might wish.
>>
>> Sure, no more than the difference between a term or a
>> concept, deprecated or not :)
>>
>> > (And even the word "deprecated" is a
>> > bit strange to me in the context of thesauri. We usually just say
>> > non-preferred.)
>>
>> Indeed? We currently in Mondeca work for a major actor in
>> legal publication (Wolters
>> Kluwer Belgium), making a very intensive use of Thesauri,
>> including e.g. their use for
>> automatic generation of publication index. And one of the
>> strong requirements of the folks
>> in charge of Thesaurus management was indeed a proper
>> handling of what they call
>> "deprecated terms". A deprecated term is a term that used to
>> be preferred, and used as
>> such, and at some point of time in the history of the
>> vocabulary was replaced by another
>> preferred term. After "deprecation" (so to speak) the
>> once-preferred, and now deprecated
>> term, is kept as a synonym of the preferred term which
>> replaces it. Whatever relationships
>> (BT-NT, USE, ...) of the deprecated term are re-located to
>> the replacing term, and
>> indexation of documents is redirected.
>>
>> So of course a deprecated term is non-preferred, but it used
>> to be, and the system keeps
>> track of that if necessary.
>>
>> > It is unusual to drop a concept altogether.
>>
>> Of course the concept does not really change because the term
>> is deprecated, since it's
>> replaced, it's simply the preferred term for it that changes.
>> Concepts never die :)
>>
>> > 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".
>> > It is conceivable that if it was decided that a large
>> subject area with
>> > perhaps hundreds of concepts was now out-of-scope, then all the
>> > corresponding terms might be dropped without trace (
>> although this is
>> > not usually recommended). The thesaurus might well be renamed or
>> > rebranded to mark the transition.
>>
>> This is another story ...
>>
>> > Much more likely would be to decide that that subject area should be
>> > indexed at a much shallower level of specificity.
>>
>> I think Thesaurus structure can (should) be kept independent
>> from the indexing
>> practices/applications that use the Thesaurus. See at the end
>> the general remak about
>> declarative vs procedural properties. Several different
>> indexing applications can use the
>> same Thesaurus at different levels of granularity, use or not
>> use specific branches etc
>> ... This is the notion of index profile (also a requirement
>> of the above quoted customer).
>> The index profile can be managed independently of the
>> structure of the thesaurus itself.
>> You can say e.g. in the profile that you only use the three
>> first levels of the Thesaurus
>> hierarchy, so whatever is indexed at a finer level of
>> granularity will be re-indexed by
>> the relevant parent.
>>
>> > 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"? All we have is one very
>> broad concept
>> > taking in tropical products at all levels of detail, and lots of
>> > non-preferred terms.
>>
>> This is quite different from deprecation, it's changing the
>> granularity of the Thesaurus.
>> And in such a case, you could just change the indexing
>> profile, saying now that "Tropical
>> Products" is a "leaf term" for the indexing profile (meaning
>> that everything below should
>> be indexed on that term).
>>
>> > So the idea of a "deprecated concept" just feels a bit alien.
>>
>> > 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?
>>
>> There again, only terms are replaced, not concepts.
>>
>> Bottom line : We need here to make distinct the *declarative*
>> properties of concepts,
>> valid whatever the context of application and the
>> *procedural* properties, applicable only
>> in specific contexts of use. For example seems to me that the
>> BT-NT relationship between
>> "Tropical Fruits" and "Bananas" should be declarative, and
>> kept existing whatever the
>> context, whereas the USE-UF relationship stated in order to
>> use the Thesaurus at a broader
>> level of granularity, is procedural: you know pretty well
>> that "Tropical Fruits" and
>> "Bananas" are distinct concepts, but in a certain context of
>> application this distinction
>> is useless for whatever reason. It's different from, say, you
>> had an ancient astronomical
>> thesaurus where "Evening Star" and "Morning Star" were
>> thought as distinct concepts, and
>> you decide/discover at some point that in fact they both have
>> to be replaced by "Planet
>> Venus". In this latter case, there is actually a
>> (declarative) change in the conceptual
>> scheme.
>> It might be that the USE-UF relationship in Thesaurus is
>> sometimes used in a declarative
>> sense, and sometimes in a procedural sense, leading to some
>> ambiguities.
>> The above quoted notion of "index profile" allows to capture
>> the procedural properties for
>> various contexts, while not changing the declarative
>> properties in the (common) Thesaurus.
>>
>> Regards
>>
>> Bernard
>>
>> Bernard Vatant
>> Senior Consultant
>> Knowledge Engineering
>> Mondeca - www.mondeca.com
>> bernard.vatant@mondeca.com
>>
>>
>>
>>
>
>


-- 
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 Monday, 11 October 2004 14:18:12 UTC