This page lists proposals for change to the SKOS Core Vocabulary and other issues related to its development.
Comments on items in this list and suggestions for new items are very welcome, please send comments and suggestions to public-esw-thes@w3.org.
Some notes about this list ...
An item in this list may be any of the following:
Note also that:
For a full description of the management process for SKOS Core see the SKOS Core Vocabulary Specification [http://www.w3.org/TR/swbp-skos-core-spec].
The usage of the skos:subjectIndicator property within the
SKOS Core Vocabulary itself, to describe properties and classes of the SKOS
Core Vocabulary is dubious, and does not fit with intended usage of this
property.
Proposed to remove all statements from the SKOS Core Vocabulary RDF/OWL
description that have skos:subjectIndicator as predicate, i.e.
that match the pattern (?x
<http://www.w3.org/2004/02/skos/core#subjectIndicator> ?y).
N.B. this is not a proposal to remove the
skos:subjectIndicator property itself.
Currently all SKOS Core documentation properties are sub-properties of
either skos:publicNote or skos:privateNote. This
means that currently e.g. a definition or a scope note must always be public,
and a change note must always be private. There is a requirement for stating
the intended audience of a note independently from the
function of the note. I.e. someone might want different definitions
for different audiences, with the notion of 'public' versus 'private' being
only one way of specifying an audience.
Proposed to deprecate the skos:publicNote and
skos:privateNote properties, and to replace these with a new
property skos:note.
Proposed to change the super-property of skos:definition
skos:scopeNote skos:example
skos:historyNote skos:editorialNote and
skos:changeNote to skos:note. So i.e. the new
documentation property hierarchy will look like:
skos:note skos:definition skos:scopeNote skos:example skos:historyNote skos:editorialNote skos:changeNote
Proposed to add a paragraph to the SKOS Core Guide recommending usage of
the dcterms:audience property to specify the audience of a note
(where the note is represented as a related resource description or a
document reference).
Currently both symbolic labelling properties have a range of
foaf:Image, however FOAF is relatively unstable. The DCMITYPE
vocabulary has an Image class and is more stable.
Also current design pattern in SKOS Core is for all property families to
descend from a single super-property, however both
skos:prefSymbol and skos:altSymbol have no
super-property, yet share some semantics.
Proposed to add new property skos:symbol with domain of
rdf:Resource and range of
http://purl.org/dc/dcmitype/Image, with a definition like 'a
symbolic label for a resource'.
Proposed to make skos:prefSymbol and
skos:altSymbol sub-properties of skos:symbol.
Proposed to remove domain and range statements from
skos:prefSymbol and skos:altSymbol (domain and
range is implied by super-property).
Labels, comments and definitions for SKOS Core classes and properties in languages other than English.
Add the following statements to http://www.w3.org/2004/02/skos/core ...
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . <http://www.w3.org/2004/02/skos/core> rdfs:seeAlso <http://www.w3.org/2004/02/skos/core_fr> . <http://www.w3.org/2004/02/skos/core> rdfs:seeAlso <http://www.w3.org/2004/02/skos/core_de> .
Concepts and Collections are supposed to be disjoint. This is stated in prose, but not formally using OWL, which it could be.
Also, there is a contradiction in the current specification of SKOS Core.
Currently SKOS Core allows concepts to be related to collections via semantic
relation properties, e.g. skos:narrower, and the Collectable
Properties Rules is used to generate the direct network of semantic
relationships between concepts. However, if a concept is related to a
collection via e.g. skos:narrower, from the Collectable
Properties Rule and the range of skos:semanticRelation, we end
up with the inference that something is both a concept and a collection,
which contradicts our assertion that these classes are disjoint.
@@TODO, see discussion of options from Alistair Miles at:
See also minimal solution described at http://lists.w3.org/Archives/Public/public-esw-thes/2006May/0021
SKOS Core does not support all the features required for the representation of many thesauri, such as special documentation/note types, semantic relations other than borader, narrower and related, special grouping constructs. However, SKOS Core may be 'extended' by declaring and using refinements of SKOS Core properties and classes. Given that many SKOS users are not familiar with this mechanism, there is a need for some simple guidelines and examples.
Previous editor's drafts of the SKOS Core Guide included some information about extension mechanisms, however these were dropped for the first PWD to speed up the publication process, with the intention that they would be added again at a later date.
To add an appendix to the next Public Working Draft of the SKOS Core Guide, giving guidelines and examples for 'extending' SKOS Core.
A proposed draft for this appendix is at:
(This draft makes extensive use of Turtle syntax for RDF, and has no diagrams. It is intended for discussion of the basic principles of extension via RDFS refinement, prior to redrafting to be more reader-friendly.)
If SKOS Core could be imported into OWL DL ontologies, and into OWL development tools, this would enable:
skos:prefLabel
skos:altLabel and skos:hiddenLabel in addition
to rdfs:label, and documentation properties such as
skos:definition, skos:example and
skos:editorialNote in addition to rdfs:comment,
for annotating classes, properties and individuals of an OWL DL
ontology.
SKOS Core cannot currently be imported into OWL DL ontologies, because:
rdf:Property and OWL
DL requires all properties explicitly typed as either
owl:ObjectProperty, owl:DatatypeProperty or
owl:AnnotationProperty.skos:prefLabel skos:altLabel and
skos:hiddenLabel are declared as sub-properties of
rdfs:label, however OWL DL forbids annotation properties to
be involved in sub-property relationships.rdfs:Class also? Need classes declared
as type owl:Class?One possible solution is to have parallel pure RDFS and OWL-DL descriptions of SKOS Core, for a discussion of this option see http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/owlImport-7.html?rev=1.1
The practice of 'pre-coordinate indexing' involves indexing resources with concepts whose meaning is derived entirely from the coordination of other concepts.
So, for example, to express the fact that the subject of some document D1 is the production of cut flowers, the indexer may coordinate the available descriptors cut flowers and production. Or, to express the fact that the subject of some document D2 is the administration and dosage of calcymicin,the indexer may coordinate the available descriptors calcymicin and administration and dosage. Note that these statements are more specific than simply indexing a resource with both descriptors, uncoordinated. The statement that the subjects of a resource are aspirin and adverse effects and calcimycin and administration and dosage, is different from the statement that the subjects of a resource are the coordination of aspirin and adverse effects (i.e. the adverse effects of aspirin) and the coordination of calcymicin and administration and dosage (i.e. the administration and dosage of calcimycin).
@@TODO
Many of the examples given in the current (2nd Public Working Draft edition) SKOS Core Guide do not give language tags on plain literals. However, it is considered good practice to use language tags, even for concept schemes labelled and documented in a single language, because the presence of language tags provides useful information where the concept scheme is being discovered and used in a multilingual context, as is inevitable once published on the web.
The intended semantics of the SKOS Core labelling properties (skos:prefLabel, skos:altLabel, skos:prefSymbol, skos:altSymbol) should be expressed at least in prose, and also formally if possible. The current specifications do not capture the intended semantics fully, and what is documented is possibly misleading.
@@TODO
SKOS does not provide support for the following structural features found in some thesauri:
This item is a placeholder for several thesaurus representation issues. It is expected that this item will be superseded by other items that provide a more specific and detailed account of each individual issue.
$Id: proposals.html,v 1.36 2007/01/18 14:53:14 ajm65 Exp $
--- $Log: proposals.html,v $ Revision 1.36 2007/01/18 14:53:14 ajm65 deprecated (roll out new skos website) Revision 1.35 2006/12/20 12:42:15 ajm65 Updated links for collections-5 Revision 1.34 2006/06/15 15:19:26 ajm65 Opened thesaurusRepresentation-11. Revision 1.33 2006/04/03 11:31:20 ajm65 Updated date of modification for coordination. Revision 1.31 2006/03/02 15:14:37 ajm65 Added labelSemantics-10 item. Revision 1.30 2006/03/01 10:08:02 ajm65 Added validation service link. Revision 1.29 2006/02/28 14:28:16 ajm65 Added link at head. Revision 1.27 2006/02/28 09:50:54 ajm65 Added prose about possible types of item on this list. Revision 1.26 2005/11/30 07:57:28 ajm65 Added link to version history Revision 1.25 2005/10/26 14:07:00 ajm65 minor editorial Revision 1.24 2005/10/26 14:05:47 ajm65 added 'coordination-8' with description of requirement, proposal @@TODO Revision 1.22 2005/10/26 10:22:29 ajm65 Updated link to revision 1.2 of draft describing options for resolving collections-5 Revision 1.21 2005/10/19 18:13:26 ajm65 added link to discussion of options for collections-5 Revision 1.20 2005/10/18 16:18:35 ajm65 added link to possible solution for owlImport-7 Revision 1.19 2005/10/18 14:08:39 ajm65 added owlImport-7 Revision 1.18 2005/10/18 12:04:01 ajm65 *** empty log message *** Revision 1.17 2005/10/17 18:35:14 ajm65 minor editorial Revision 1.16 2005/10/11 12:00:33 ajm65 minor editorial Revision 1.14 2005/10/06 15:06:46 ajm65 updated status of subjectIndicatorUse-1, notes-2, symbolicLabelsRange-3, and seeAlsoTranslations-4 to CLOSED. Revision 1.13 2005/09/01 14:59:23 ajm65 Updated format, uniform Revision 1.12 2005/07/11 11:24:41 ajm65 added seeAlsoTranslations-4 Revision 1.11 2005/07/01 14:03:57 ajm65 added symbolicLabelsRange-3 proposal Revision 1.10 2005/06/22 18:41:28 ajm65 fixed CVS log Revision 1.9 2005/06/22 18:35:26 ajm65 superficial Revision 1.8 2005/06/22 18:32:43 ajm65 fix keywords Revision 1.7 2005/06/22 18:25:55 ajm65 fix Revision 1.6 2005/06/22 18:25:05 ajm65 added cvs log and id Revision 1.5 2005/06/16 17:27:01 ajm65 fixed title Revision 1.4 2005/06/15 11:17:10 ajm65 added notes-2 proposal Revision 1.3 2005/06/01 17:08:56 ajm65 removed dummy proposal, added subjectIndicatorUse-1 proposal Revision 1.2 2005/05/04 16:57:10 ajm65 minor eds Revision 1.1 2005/05/04 16:54:40 ajm65 initial version with dummy proposal ---