The goal of this discussion is to make some initial decisions about what features are in the SKOS Reference recommendation, and what features are left out (to be done later as an extension/add-on or left to the community), without going into detail on the design of any of those features.
It's suggested that we be very strict with ourselves, and give each feature no more than 10 minutes discussion. If a consensus emerges in that time, then we agree and move on. If no consensus emerges then we move on anyway, and come back to the decision when we look at the relevant issues in more detail later in the agenda. With 12 features listed below, that's 2 hours total needed for scoping discussion.
Hopefully, this should give us a picture of the scope of the Recommendation. Our initial decisions don't have to be set in stone, the idea is just to focus later discussion and help prioritise our time.
Maybe take some of the easy ones first, to get warmed up ... ?
Feature: Notations
Support for notations (a.k.a. classification codes) e.g. as used in DDC.
Reasons for in:
- notations are a common feature of classification schemes, central to their use
- minimal impact on current data model, uncontroversial
Reasons for out:
- not common to all KOS (e.g. not used in most thesauri)
- could be supported as extension or even note on usage of existing vocab
See also: ISSUE-79
Feature: (Subject) Indexing
Support for (subject) links between information resources (documents) and concepts. Previous versions of SKOS included skos:subject, skos:isSubjectOf, skos:primarySubject, skos:isPrimarySubjectOf.
Reasons for in and out discussed in SkosDesign/Indexing
Feature: Symbol (Image) Labels
Support for labeling resources with images (PNGs, GIFs etc.)
Previous versions of SKOS included skos:prefSymbol, skos:altSymbol.
Reasons for in:
- quick and easy way to enrich visualisation of KOS with images
Reasons for out:
- no supporting use cases
- data model hard to pin down precisely
- could be done as add-on with little dependency on core features
See also: ISSUE-76
Now some harder ones ... ?
Feature: Mapping Between Concept Schemes
Support for asserting mapping links between concepts in different schemes.
Current SKOS Reference WD defines skos:exactMatch, skos:broadMatch, skos:narrowMatch, skos:relatedMatch.
Reasons for in:
- important part of use of KOS in networked environment
- experience of use in real applications (e.g. Agrovoc)
Reasons for out:
- several aspects of data model are currently contentious, arguably needs more study/experience (e.g. broadMatch subPropertyOf broader? broadMatch disjointWith broader? broadMatch disjointWith exactMatch? ...)
- some aspects of usage also contentious (e.g. what do you use to "enrich" a concept scheme?)
- could be done as extension/add-on (although likely strong dependency on core features)
Feature: Labels as Resources
Support for naming lexical entities with URIs, making statements about them, and using them to label concepts.
SKOS-XL draft defines a SKOS extension with support for these features (xl:Label, xl:prefLabel, xl:altLabel, xl:hiddenLabel).
Reasons for in:
- required by several use cases
Reasons for out:
- don't want to force implementations to support it
- can be defined within an extension module
- relatively immature, no implementation experience
N.B. there are more than two choices for this feature, e.g. this feature could be provided within the SKOS Reference recommendation, but as an explicit SKOS extension using a different namespace which implementations don't have to support. Or e.g. this feature could be supported as a SKOS extension published as a Note outside the recommendation.
See also: SKOS-XL proposal, ISSUE-26, ISSUE-27
Feature: Label Relations
Support for asserting links between lexical entities, e.g. acronym, transliteration etc.
Current SKOS Reference includes support for n-ary relations between RDF plain literals. SKOS-XL draft extension has support for three alternate patterns for label relations.
Reasons for in:
- required by several use cases
Reasons for out:
- can be defined within an extension module
- relatively immature, no implementation experience
- no consensus on which of three known patterns is "best"
See also: SKOS-XL proposal, ISSUE-26, ISSUE-27
Feature: Reference Semantic Relation Specialisations (broaderGeneric etc.)
Support for specific extensions of broader, narrower, e.g. broaderGeneric, broaderInstantive, broaderPartitive.
These were previously defined in a "SKOS Extensions" vocab, but never published as WD.
Reasons for in:
- used in some kos
- provides migration path to ontology
Reasons for out:
- data model is unclear
- current proposals may impact/restrict usage patterns for SKOS with OWL ("crossing the streams")
- treading on OWL's toes
- could be done as extension
See also: ISSUE-56
Feature: OWL Imports
Support for importing one SKOS dataset into another.
Current SKOS Reference and Primer WDs have words on using owl:imports.
The main question is, do we leave the door open for using owl:imports (in)? Or do we ignore it (out)?
Reasons for in:
- maybe useful for "extending" kos
Reasons for out:
- usage patterns unclear
- expected behaviour unclear
See also:
Feature: SKOS Imports
Support for importing (including?) one SKOS concept scheme in another. Also, support for including specific concepts from one scheme into another.
No current proposals for this, but mentioned in several emails.
Reasons for in:
- maybe useful for "extending" kos
Reasons for out:
- no well-understood proposals
- usage patterns unclear
- expected behaviour unclear
See also: ISSUE-119
Feature: Coordinated Subject Indexing
Support for indexing documents with "coordinations" of concepts.
Reasons for in:
- important for use of subject heading schemes in particular
- provides support for more precision in IR applications
Reasons for out:
- no implementation experience
- could be done as extension/add-on
See also: ISSUE-40
Feature: XML Literal Notes
Support for documenting concepts with XML content, e.g. XHTML, MathML, SSML.
Reasons for in:
- enable rich annotation of concept, use of multimedia languages
Reasons for out:
- no mature proposals
- could be done in extension / add-on
See also: ISSUE-65
Feature: N-ary Thesaurus Patterns
Support for standard thesaurus pattern A USE B + C. Support for non-standard thesaurus pattern A USE B OR C.
Reasons for in:
- standard pattern found quite widely, non-standard pattern also used
Reasons for out:
- no mature proposal
- possibly could do in extension/add-on
See also: ISSUE-45