W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2008

RE: RE: revisions and change in skos

From: Joseph Tennis <jtennis@u.washington.edu>
Date: Wed, 1 Oct 2008 13:03:18 -0700
To: "public-esw-thes@w3.org" <public-esw-thes@w3.org>
Message-ID: <921C5050BE9E3B4B9DE545554A42253E02210EAE75@ads-mbx-01.exchange.washington.edu>


Did you find any of the stuff Stuart and I talked about in JASIST of help with your project?  Are dcterms useful in the models presented in that paper?


Joseph T. Tennis
Assistant Professor
The Information School of the University of Washington



-----Original Message-----
From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Panzer,Michael
Sent: Wednesday, October 01, 2008 8:20 AM
To: public-esw-thes@w3.org
Subject: RE: revisions and change in skos

Hi Rob,

I am currently dealing with similar problems and have been experimenting
with using DCMI terms:

For deprecation (vacating a concept completely) I am using

<Concept rdf:about="a">
  <historyNote rdf:parseType="Resource">
    <dcterms:isReplacedBy rdf:resource="b"/>

However, it is debatable if the added semantics induced by the history
note property warrant the creation of a blank node in your resource
description, or if dcterms:isReplacedBy should be used directly outside
of the note.

In addition, some other DC terms like dcterms:created, dcterms:updated,
dcterms:issued, dcterms:coverage and dc:isVersionOf come in handy for
indicating version dependencies.


-----Original Message-----
        From: Rob Tice [mailto:rob.tice@k-int.com]
        Sent: Mon 9/29/2008 13:53
        To: Sini, Margherita (KCEW)
        Cc: public-esw-thes@w3.org
        Subject: 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

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

Best Regards

Received on Wednesday, 1 October 2008 20:18:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:10 UTC