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
dcterms:isReplacedBy:

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

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.

Cheers
Michael

-----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
case.

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

Best Regards

Rob

Received on Wednesday, 1 October 2008 19:24:21 UTC