Re: Status of SKOS resources (stable, testing etc) : supersededBy ???

Hi everyone,

If the discussion is being moved slowly towards representation of different versions of concepts, you might be interested to have a look (and add) to this wiki page: http://www.w3.org/2001/sw/wiki/SKOS/Issues/ConceptEvolution :-)

Cheers,

Antoine


> Hi Christophe,
>
> On Mon, Jul 05, 2010 at 06:36:22PM +0200, Christophe Dupriez wrote:
>> What would be an elegant way to represent supersession (superseded /
>> superseding) as a relation between two concepts
>> OR as a simple trace of a previous identifier redirected to a new
>> one (like with HTTP status 301 where the old page is not
>> accessible)?
>
> I haven't thought about this very deeply, but I think I would do both.
>
> I.e., add...
>
> <http://example.org/concepts/X>  dcterms:isReplacedBy<http://example.org/concepts/Y>  .
>
> ...to my triples, and make sure that...
>
> GET /concepts/X
> Host: example.org
>
> ...returns...
>
> 301
> Location: http://example.org/concepts/Y
>
> ...although thinking about this a bit more, this does mean that if you
> were ever interested in data about the superseded concept, you
> wouldn't be able to retrieve the data directly (because of the
> 301). So now I'm not sure if the 301 is a good idea.
>
> Btw, dcterms [1] has dcterms:replaces and dcterms:isReplacedBy which
> are possibly suitable.
>
> Cheers
>
> Alistair
>
> [1] http://dublincore.org/documents/dcmi-terms/#terms-replaces
>
>>
>> My two cents:
>> 1) renaming my "alias" field to "superseding" which can be a literal
>> (old Identifier of deleted concept) or a relation (URL of
>> deprecated/retired concept).
>>      This shows that a superseded concept can be deprecated
>> (retirement cannot be complete because old data must be reindexed)
>>       or retired (no more data uses the superseded concept but one
>> wants to keep trace of it). This requires an independent
>> "supersededBy" field.
>> 2) adding an optional "supersededBy" relation containing the URL of
>> the new Concept
>>      (or ConceptS if the replacements request a human decision,
>> indexed record by indexed record)
>>
>> Have a nice evening,
>>
>> Christophe
>>
>> Le 30/06/2010 14:33, Simon Cox a écrit :
>>> Now I've seen how the appalling webmail client provided by my employer
>>> garbled that I think it is worth trying again:
>>>
>>> 8.8.4 status
>>> The derived attribute status shall be represented as an instance of
>>> RE_ItemStatus (8.20) that identifies the
>>> registration status of the RE_RegisterItem. The value is derived through the
>>> Addition and Amendment
>>> associations as specified by the constraint:
>>>
>>> {if
>>> 	exists ->   (self.amendmentInformation.amendmentType = #retirement
>>> 		and self.amendmentInformation.disposition = #accepted
>>> 		and self.amendmentInformation.status = #final)
>>> 	then self.status = #retired
>>> else if
>>> 	exists ->   (self.amendmentInformation.amendmentType = #supersession
>>> 		and self.amendmentInformation.disposition = #accepted
>>> 		and self.amendmentInformation.status = #final)
>>> 	then self.status = #superseded
>>> else if
>>> 	exists ->   (self.additionInformation.disposition = #accepted
>>> 		and self.additionInformation.status = #final)
>>> 	then self.status = #valid
>>> else self.status = #notValid
>>> endif}
>>>
>>> (I guess this is OCL.)
>>>
>>> --------------------------------------------------------
>>> 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.
>>>
>>> -----Original Message-----
>>> From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org]
>>> On Behalf Of Simon Cox
>>> Sent: Tuesday, 29 June 2010 19:11
>>> To: Christophe Dupriez
>>> Cc: 'Sue Ellen Wright'; 'Matthias Löbe'; 'Bernard Vatant'; 'Alistair Miles';
>>> 'Dan Brickley'; 'Marc Wick'; 'Dublin Core'; 'SKOS'; 'Leigh Dodds'; 'Libby
>>> Miller'; 'Lise Rozat'; Dominique Vanpée; Wim Daeleman
>>> Subject: RE: Status of SKOS resources (stable, testing etc)
>>>
>>> Here is the logic as described in ISO 19135:
>>>
>>> 8.8.4 status
>>> The derived attribute status shall be represented as an instance of
>>> RE_ItemStatus
>>> (8.20) that identifies the registration status of the RE_RegisterItem. The
>>> value is derived through the Addition and Amendment associations as
>>> specified by the constraint:
>>>
>>> {if
>>> exists ->   (self.amendmentInformation.amendmentType = #retirement and
>>> self.amendmentInformation.disposition = #accepted and
>>> self.amendmentInformation.status = #final) then self.status = #retired else
>>> if exists ->   (self.amendmentInformation.amendmentType = #supersession and
>>> self.amendmentInformation.disposition = #accepted and
>>> self.amendmentInformation.status = #final) then self.status = #superseded
>>> else if exists ->   (self.additionInformation.disposition = #accepted and
>>> self.additionInformation.status = #final) then self.status = #valid else
>>> self.status = #notValid endif}
>>>
>>>
>>>> -- Original Message --
>>>> Date: Tue, 29 Jun 2010 18:54:48 +0200
>>>> From: Christophe Dupriez<christophe.dupriez@destin.be>
>>>> Subject: Status of SKOS resources (stable, testing etc)
>>>>
>>>>
>>>> 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, 6 July 2010 09:57:28 UTC