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 Wednesday, 3 August 2005 13:55:19 UTC