FW: SKOS Core second review - changeNote

Mark and Alistair have raised some issues about changeNote. This is a
new type of note as far as I am concerned - I've never seen it used. But
I am wondering whether it might apply to a vocabulary I am working with
now...

In the track record of this vocabulary, it has been the established
practice to use a field called History Notes to record every single
change that has happened to a term (Yes, in this vocabulary the notes
apply to terms and not necessarily to concepts), some of the notes e.g.
"Introduced in Version 2.0" may be useful to searchers, but mostly they
seem to be intended for system administrators, so they can implement
successive updates, tying each term in the latest version with whatever
use they have made of the corresponding term in the previous version (
including mappings to their in-house vocabularies). As an added
complication, one such administrator said to me that he hoped to move
from Version X to Version X+3, without having to implement the
successive intermediate updates, and he hoped these notes were going to
help him with that. 

I just cannot imagine how the updates can be implemented automatically,
without human inspection of precisely the nature of each change, and
whether or not, or how it has implications for their in-house systems.
Some past examples of these notes include, "Copied from 1 - Business to
3300 - Business and street trading licences in version 1.03"; "Changed
to non-preferred in 1.02"; "Moved within the hierarchy in 1.02". I'm
afraid I can't see how such notes can be implemented automatically.

But maybe changeNote is the vehicle to carry advice for implementers
rather than users? Maybe some messages could be really helpful in the
implementation of updates? I raise these questions in the hope that
someone on the list can advise on the type of note that is useful to
implementers.

Thanks
Stella

*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
SDClarke@LukeHouse.demon.co.uk
*****************************************************



-----Original Message-----
From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org] On Behalf Of Miles, AJ
(Alistair)
Sent: 03 August 2005 14:55
To: Mark van Assem; public-esw-thes@w3.org
Subject: RE: SKOS Core second review



Hi Mark,

Thanks for this.  Responding to specific comments ...

> 
> * notes-2
> 
> Review proposal notes-2 [1] says "There is a requirement for stating 
> the intended audience of a note independently from the function of the

> note".
> 
> With that in mind I am wondering about the following properties:
> 
> - skos:historyNote "A note about the past state/use/meaning of a 
> concept."
> - skos:changeNote "A note about a modification to a concept."
> - skos:editorialNote "A note for an editor, translator or maintainer
> of the vocabulary."
> 
> The editorialNote seems to mix up audience and function, and could be 
> replaced by usage of either skos:historyNote or skos:changeNote with 
> the appropriate audience attached to it.

You're right, there is a bit of a mix-up between audience and function,
but I think skos:editorialNote is best kept, primarily because it aligns
with BS8723, other accepted standards, and best practice in the
thesaurus world.

> 
> I also am still wondering about the overlap between skos:historyNote 
> and skos:changeNote (is the difference large enough to warrant 
> separate properties?), but maybe that is best left until after the 
> review.

The original idea was that the editor records a skos:changeNote for
every single (possibly minor) change, i.e. skos:changeNotes are a bit
like the comment you add to every commit you make to a CVS repository.
A skos:historyNote is a note intended more for public (indexer/searcher)
consumption, recording information about a change leading to modified
usage.  The skos:historyNote property was intended to be used as
described in BS8723, which seemed different from the use of
skos:changeNote to record all modifications, as in the SKOS Core
vocabulary itself e.g.

  <rdfs:Class rdf:ID="ConceptScheme">
    <skos:changeNote rdf:parseType="Resource">
      <rdf:value>Definition modified from 'A description of a set of
concepts, which may include a description of relationships between those
concepts'.  Comment added 'Thesauri, classification schemes, subject
heading lists, taxonomies, terminologies, glossaries and other types of
controlled vocabulary are all examples of concept schemes'.  Change to
bring in line with SKOS Core Guide and definition at Willpower
Glossary.</rdf:value>
      <dc:date>2005-02-09</dc:date>
      <dc:creator>Alistair Miles</dc:creator>
    </skos:changeNote>
    <skos:changeNote rdf:parseType="Resource">
      <rdf:value>Reworked the definition, in line with new guide.
Concept scheme now defined as 'a *description* of a set of concepts,
which may include a description of relationships between those
concepts'.  This change made to make explicit the fact that semantic
relationships between concepts may be part of a concept scheme. Also
expresses modelling concept scheme as an information resource (hence the
'description' word added).</rdf:value>
      <dc:date>2004-12-17</dc:date>
      <dc:creator>Alistair Miles</dc:creator>
    </skos:changeNote>
    <skos:changeNote rdf:parseType="Resource">
      <rdf:value>Added a definition; added an example; deprecated old
comment; added new comment; added xml:lang value to label.</rdf:value>
      <dc:date>2004-10-20</dc:date>
      <dc:creator>Alistair Miles</dc:creator>
    </skos:changeNote>
  </rdfs:Class>
	
Lately I'm thinking that change information like the above should be
represented as statements about graphs, rather than about the resource
being changed, because they describe changes to a set of triples, rather
than to a resource.  I describe this pattern in [1].  However, that's
more a general RDF management issue that isn't going to take longer to
work out, and I think the use of skos:changeNote as above is quite
reasonable for now.

> 
> * symbolicLabelsRange-3:
> 
> Looking into dcmitype:Image [2] I noticed that it is not only a class 
> but an instance as well (of dcterms:DCMIType). This seems tricky for 
> us, as this means that as soon as software (interpreting skos:Concepts
> with skos:symbol attached to it) also imports the whole dcmitype 
> vocabulary, we're outside OWL DL. Seems that we gain a little 
> and risk 
> a lot in this way by moving to dcmitype:Image. But this question must 
> have popped up with others, so maybe most don't see this as a 
> problem? 
> Can anyone comment on this?
> 

SKOS Core is already outside OWL DL because we allow flexibility in the
range of the documentation properties.  OWL DL requires that all
properties be declared as either datatype properties or object
properties.  So I think dcmitype:Image is OK for use with SKOS Core.  

I think we should accept that SKOS Core is firmly outside OWL DL for
now, and respond only to significant use cases that require DL
functionality as and when they arise.  I think we should attack
SKOS/OWL/DL questions like this at the next (3rd) review, with someone
from SWBP OEP TF as reviewer and in co-ordination with OEP, attempting
to answer questions like:

(a) Should the SKOS Core Vocabulary conform to OWL DL?

(b) Should the classes skos:Concept and owl:Class be disjoint?

(c) Should the classes skos:Concept and rdf:Property be disjoint?

That's it for now.

Cheers,

Al.

[1] http://esw.w3.org/topic/ConfigurationManagement

Received on Thursday, 4 August 2005 19:53:26 UTC