RE: revisions and change in skos

Hi Margherita

Thanks for the response.

When it comes to change control one of our main use cases is so that other systems can gain all the info that they need to ensure that updates and mappings are cascaded to end users of the reference data. 

I can see that your proposed solution could be a usable work around in certain cases, however our actual goal is to expose a link between concept a and b to inform systems that any previous reference to the uri of concept a should now use the uri for concept b. To that end for us the deprecation part of the work around is actually a different use case.

How do you/the list think we should present this link info?

Best Regards

Rob




> -----Original Message-----
> From: Sini, Margherita (KCEW) [mailto:Margherita.Sini@fao.org]
> Sent: 29 September 2008 09:30
> To: Rob Tice
> Cc: public-esw-thes@w3.org
> Subject: RE: revisions and change in skos
> 
> For point 2. I would suggest:
> 
> -  leave 'concept a' as deprecated. Its uri will remain but some status
> should be set as deprecated. No URI can be eliminated.
> - assign a new uri to concept 'b' and keep 'a' as non preferred label
> for it.
> 
> Hope this helps,
> Regards
> Margherita
> 
> 
>  -----Original Message-----
>  From: public-esw-thes-request@w3.org on behalf of Rob Tice
>  Sent: Mon 9/29/2008 08:57
>  To: public-esw-thes@w3.org
>  Cc:
>  Subject: revisions and change in skos
> 
> 
> 
> 
>  Dear list members
> 
>  The background to my questions is that we are currently
> considering
>  developing a
>  'SKOS resolver' (for want of a better description) for our
>  terminology management solution to sit alongside the other
> formats we
>  currently implement.
> 
>  This has however thrown up some questions.
> 
>  As part of this requirement we (ideally)need to:
>  1 Expose versioning information
>  2 Allow identification of terminology changes between versions
> 
>  As these are parts of our existing solution which are already
> exposed
> using
>  other formats.
> 
>  So...
> 
>  1. How should we expose versioning information given that uri's
> for
>    concepts are fixed (please don’t say timestamps on
>    uri's :))
> 
>  2. How should we identify and manage change between revisions of
> concept
>  schemes as this 'seems' to result in imprecision.
>     e.g. a concept 'a' is currently in thes 'A' and only has a
> preferred
>  label. A new revision of thes 'A' is published and what was
> concept
> 'a'
>     is now a non preferred concept and thus becomes simply a non
> preferred
>  label
>     for a new concept 'b'.
> 
>     It seems to me that this operation loses some
>     of the semantic meaning of the change as all references to the
>     concept id of 'concept a' would be lost as it now is only a
> non
> preferred
> 
>     label of a different concept with a different id (concept
> 'b').
> 
>  Any comments would be much appreciated.
> 
>  Best Regards
> 
>  Rob
> 
> 
>  -----------------------------------------------------------------
> -
> 
> 
>  Rob Tice, Director
>  Knowledge Integration Ltd
>  35 Paradise Street
>  Sheffield
>  South Yorkshire
>  S3 8PZ
>  email: rob.tice@k-int.com
>  Tel: +44 (0)870 803 4661
>  http://www.k-int.com <http://www.k-int.com/>
> 
>  No virus found in this outgoing message.
>  Checked by AVG.
>  Version: 7.5.524 / Virus Database: 270.7.4/1695 - Release Date:
> 27/09/2008
>  13:11
> 
> 
> 
> 
> 
> 
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 270.7.5/1696 - Release Date:
> 28/09/2008 13:30
> 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.7.5/1696 - Release Date: 28/09/2008 13:30

Received on Monday, 29 September 2008 11:54:51 UTC