RE: candidate and deprecated concepts

Carl wrote:
> 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' ? :-} .

The idea of a 'candidate' I took from traditional thesaurus practise ... so
when new terms are suggested as part of the evolution process, they first
become 'candidates' for membership in the thesaurus.  If after evaluation
they are then accepted as full members, they are no longer candidates.

This is distinct from the notion of 'deprecation', which I mean to describe
a concept that should no longer be used for indexing.

N.B. within SKOS Core I would like to be able to make statements about
*concepts* as candidates in a scheme.

(If someone were to suggest adding a new term as a non-preferred label of an
existing concept, this would be modelled as a 'proposed change to an
existing concept', and *not* as the introduction of a 'candidate term'.)

Note also, it is perfectly reasonable to publish a concept or set of
concepts, *without* any statements about which *scheme(s)* they are a part
of.  In this sense, it is useful for the publishing authority to be able to
state to what extent the concept is *stable* i.e. to what degree it may be
expected to change in the future.

Obviously there is a connection between these two notions ('status' and
'stability'), because it would not be good practise to accept a concept as
part of a thesaurus if it was still unstable.  However, I believe the two
notions are functionally independent.

As a point of interest, I would like to encourage a perspective shift.
Within a semantic web context I think it makes better sense to think of the
first step being for an authority (or individual) to publish a set of
concepts.  Concept schemes may then be described a posteriori to include all
or some of these published concepts.  This allows for schemes to be
described that include concepts from multiple sources.  I.e. a concept has
an existence and a publication status that is independent of the schemes (or
scheme versions) which it participates in.

Carl wrote:
> 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'.

This is in effect what will be achieved if we can encourage explicitly
concept-oriented subject indexing.

Al.



> -----Original Message-----
> From: Carl Mattocks [mailto:carlmattocks@checkmi.com]
> Sent: 11 October 2004 15:18
> To: Miles, AJ (Alistair)
> Cc: 'Bernard Vatant'; Stella Dextre Clarke; public-esw-thes@w3.org
> Subject: RE: candidate and deprecated concepts
> 
> 
> et Al:
> 
> 
> 
> 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 15:43:43 UTC