- From: Christophe Dupriez <christophe.dupriez@destin.be>
- Date: Tue, 29 Jun 2010 18:54:48 +0200
- To: Simon Cox <simon.cox@jrc.ec.europa.eu>
- CC: 'Sue Ellen Wright' <sellenwright@gmail.com>, 'Matthias Löbe' <matthias.loebe@imise.uni-leipzig.de>, 'Bernard Vatant' <bernard.vatant@mondeca.com>, 'Alistair Miles' <alimanfoo@googlemail.com>, 'Dan Brickley' <danbri@danbri.org>, 'Marc Wick' <marc@geonames.org>, 'Dublin Core' <DC-ARCHITECTURE@jiscmail.ac.uk>, 'SKOS' <public-esw-thes@w3.org>, 'Leigh Dodds' <leigh.dodds@talis.com>, 'Libby Miller' <Libby.Miller@bbc.co.uk>, 'Lise Rozat' <lise.rozat@mondeca.com>, Dominique Vanpée <dominique.vanpee@poisoncentre.be>, Wim Daeleman <wim.daeleman@poisoncentre.be>
- Message-ID: <4C2A2558.2020208@destin.be>
Hi Simon, You propose an orthogonal representation of the NSDL RegStatus proposal. I was (like you) feeling it would be better up to the moment I saw that a workflow would be needed (only precise state changes would be allowed). Then the NSDL RegStatus seemed a constrained list of possible combinations of the 3 dimensions you indicate. Whatever is the representation, we need now a table of permitted status changes (being one or three variables) with the question asked at each step: it may then be possible to define this to a workflow engine and have for "free" a terminology collaboration system! http://java-source.net/open-source/workflow-engines Anyone knows what is working in practice in this domain? A simple attempt to fully modelize a workflow is below: (S are states, Q are questions, X are eXceptions/eXits from normal path): S1: New-Proposed (notValid or retired or superseded if coming from S9, accepted,pending) [set by ANYONE] Q1: Please Improve up to the point it makes an acceptable proposal for the validation committee! X1:Rejected (retired or superseded/notAccepted/final) or continues to: S2: New-Under review (notValid or retired or superseded if coming from S9, accepted,tentative)[set by THESAURUS MANAGER] Q2: Does the validation committee accept this new contribution? X2:Rejected S9 (retired/notAccepted/final) or continues to: S3: Published (valid, accepted,final)[set by VALIDATION COMMITTEE] Q3: Some problems with this? (change, deprecate?) S4: Change-Proposed (valid,accepted,pending) [set by ANYONE] Q4: Please Improve up to the point it makes an acceptable change for the validation committee! X6: return to S3 or continues to: S5: Change-Under review (valid,accepted,tentative) [set by THESAURUS MANAGER] Q5: Does the validation committee accept this change? APPLY COMMITTEE DECISION and then return to S3 S6: Deprecate-Proposed (valid,withdrawn,pending)[set by ANYONE] Q6: Please justify up to the point it may accepted by the validation committee! X6: return to S3 or continues to: S7: Deprecate-Under review (valid,withdrawn,tentative) [set by THESAURUS MANAGER] Q7: Does the validation committee accept this deprecation? X7: return to S3 or continues to: S8: Deprecated (retired or superseded, withdrawn,final)[set by VALIDATION COMMITTEE] Q8: No more information linked with this? X8: Necessary to reactivate, ANYONE can put back in S1 ? or continues to: S9: Rejected (retired or superseded/notAccepted/final) [set by THESAURUS MANAGER, may be automated] Q9: Do we still feel rejecting this? X9: Necessary to reactivate, ANYONE can put back in S1 ? My colleagues may help me validate this and make a nice graph, it would really help! Have a nice evening! Christophe Le 29/06/2010 17:31, Simon Cox a écrit : > Also possibly of interest are the values in several enumeration > classes in ISO 19135 (Procedures for registration): > RE_ItemStatus:: > notValid (i.e. submitted but not yet processed) > valid > superseded (i.e. no longer valid but replaced by another item in > the register) > retired (i.e. no longer valid but not replaced). > RE_Disposition:: > withdrawn > accepted > notAccepted > RE_DecisionStatus:: > pending > tentative > final > As you can see, this model elaborates the status values on several axes. > > -------------------------------------------------------- > *Simon Cox > * > European Commission, Joint Research Centre > Institute for Environment and Sustainability > Spatial Data Infrastructures Unit, TP 262 > Via E. Fermi, 2749, I-21027 Ispra (VA), Italy > Tel: +39 0332 78 3652 > Fax: +39 0332 78 6325 > mailto:simon.cox@jrc.ec.europa.eu > http://ies.jrc.ec.europa.eu/simon-cox > > SDI Unit: http://sdi.jrc.ec.europa.eu/ > IES Institute: http://ies.jrc.ec.europa.eu/ > JRC: http://www.jrc.ec.europa.eu/ > > -------------------------------------------------------- > > Any opinions expressed are personal unless otherwise indicated. > > > ------------------------------------------------------------------------ > *From:* public-esw-thes-request@w3.org > [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Sue Ellen > Wright > *Sent:* Thursday, 24 June 2010 18:13 > *To:* Matthias Löbe > *Cc:* Bernard Vatant; Alistair Miles; Dan Brickley; Marc Wick; > Dublin Core; SKOS; Leigh Dodds; Libby Miller; Lise Rozat > *Subject:* Re: Status of resources (stable, testing etc) > > Dear Colleagues, > I am sending an HTML output from the TC 37 ISOcat Metadata > Registry (Data Category Registry) That shows our entry for > //administrative status//, which in many local termbases would > probably appear simply as //term status/. /We have issues within > the collection with distinguishing between different status > values, which is why the standardized data category looks a little > too complicated. The values are indeed the ones that Matthias has > identified in 10241 and they are widely used throughout TC 37 > standards and within the terminology management community. (Bear > in mind we are talking discourse/text-oriented terminology here, > which doesn't always behave the same way that SKOS terminology > does, but we've got lots of cross-over points of reference.) If > you look at this file in a browser and move down to the value > domain that is shown at the end, you can link to any one of the > data category specifications that are referenced there. You'll > find that "deprecated" refers to simply any term that is not > considered acceptable, whether it has always been unacceptable or > it has been changed to that status at some time. You will note > that this is something of a bone of contention, because some > linguists don't like the term and prefer to say "not recommended" > in this slot. Frankly, I don't really care what label people use > as long as they document the mapping to the right data category > definition. If you really want to specify that a term was once > used as accepted or preferred, but it has been rejected and > replaced by another term, you can use "superseded". In practice, > most people simply use "preferred", "admitted", and "deprecated" > (or "not recommended" if they belong to that camp). > BTW, the links are mnemonic representations of non-mnemonic > persistent identifiers that resolve the display you will see > through our RESTful interface. If anybody is interested in > referencing concepts from TC 37, we'd love to show you how this > works. We're also advocates of this kind of permanent linking > mechanism between web resources of all kinds, although not > everybody has the simple solution of using a registered ISO domain > to back up a cool URI. Check out ISOcat at http://www.isocat.org > <http://www.isocat.org/>. > Bye for now > Sue Ellen Wright, Chair, ISOcat Data Category Registry Board > > 2010/4/29 Matthias Löbe <matthias.loebe@imise.uni-leipzig.de > <mailto:matthias.loebe@imise.uni-leipzig.de>> > > Hello to all, > > ISO 10241 "International terminology standards" has a scale of > acceptability ratings comprised of: "preferred", "admitted", > "deprecated", "obsolete" and "superseded". > > Well, I always read "deprecated" as outdated, obsolete, > superseded, > archaic, "was once approved, but should not used furthermore". > > In contrast, I see cases where someone would like to express a > status > "disapproved" as "We know it might be intuitive to raise such a > concept and we've discussed it, but for good reason we > declined it and > won't discuss it again." (e.g. when a designation is not best > practice > in a certain context). > > M > > -- > Matthias Löbe, Inst. for Medical Informatics (IMISE), > University of Leipzig > Härtelstr. 16, D-04107 Leipzig, +49 341 97 16113, > loebe@imise.uni-leipzig..de > > > > > > -- > Sue Ellen Wright > Institute for Applied Linguistics > Kent State University > Kent OH 44242 USA > sellenwright@gmail.com <mailto:sellenwright@gmail.com> > > Terminology management: There is unfortunately no cure for > terminology; you can only hope to manage it. (Kelly Washbourne) >
Received on Tuesday, 29 June 2010 16:56:19 UTC