This is an archive of an inactive wiki and cannot be modified.

Semantic Web Deployment WG Face-to-Face Meeting


Phone bridge


SKOS Required Reading

SKOS schedule (pending approval of charter extension)

The remaining schedule for SKOS is as follows:

SKOS Ongoing actions

Agenda Item: SKOS Scoping Discussion (120 mins)

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

See also: ISSUE-48, ISSUE-77

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)

See also: ISSUE-71, ISSUE-74

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

Agenda Item: SKOS Technical Discussion

The goal of this discussion is to make decisions about technical issues which have an impact on the SKOS Reference recommendation.

The points below provide only the outline of a discussion. How we order the points and whether we skip any will depend on the outcome of the scoping discussion. It's suggested we spend 10 mins or so prioritising these items before we start.

Technical Item: SKOS Namespace (@@TODO mins)

What namespace will we use for the SKOS vocabulary?

How will the namespace dereference?

Technical Item: Related Irreflexive? Broader Irreflexive? Broader Cycles? (Issues 68, 69, 70) (@@TODO mins)

Issues tracker: ISSUE-68, ISSUE-69, ISSUE-70

Note that a reflexive relation has every object related to itself. An irreflexive relation has no object related to itself.

These three issues can be discussed together. We are likely to answer either yes to all or no to all, depending on whether we favour a stronger or weaker data model for SKOS semantic relations.

If we favour a stronger data model, then we answer yes to all three. The advantage is that we provide a stronger endorsement for checking consistency w.r.t. a model that (almost?) all thesauri, classification schemes and taxonomies adhere to. However, a stronger data model may close the door on some SKOS/OWL patterns.

If we favour a weaker data model, then we answer no to all three. The advantage is flexibility, which leaves the door open for certain patterns for using SKOS and OWL together (note that rdfs:subClassOf is reflexive).




Technical Item: SKOS Mapping, Data Model and Usage (Issues 71, 73, 74, 75) (@@TODO mins)

All preparatory material for this agenda item is given at the following link: WashingtonAgenda/MappingIssues

Technical Item: Labels as Resources, Label Relations (Issues 26, 27) (@@TODO mins)

Issues tracker: ISSUE-26, ISSUE-27

The first decision point here is, do we move all support for label relations out of the SKOS vocabulary and into XL?

The second decision point is, do we publish XL as part of the SKOS Recommendation? If so, is it an appendix to the SKOS Reference, or is it a separate document?

We should continue discussion here *only if* we have previously agreed that XL is part of the SKOS Recommendation. Otherwise, we should move on to other issues in scope, and postpone detailed discussion of XL.

If XL is to be part of the recommendation, then:

  • How do we make it clear that we don't expect all SKOS implementations to support XL, that it is an optional extension?
  • What is the XL namespace? ?

  • How does the XL namespace dereference?
  • Any issues with the XL vocabulary and data model?


  • None


Discussion and comments (most recent first):

Pattern: n-ary relations between plain literals ...

  <skos:altLabel>World Health Organization</skos:altLabel>
      <ex:fullForm>World Health Organization</ex:fullForm>

Pattern: binary relations between instances of xl:Label ...

    <xl:Label rdf:about="L1">
    <xl:Label rdf:about="L2">
      <xl:literalForm>World Health Organization</xl:literalForm>
      <ex:acronym rdf:resource="L1"/>

Technical Item: Indexing Properties (Issues 48, 77) (@@TODO mins)

All preparatory material for this agenda item is given at the following link: SkosDesign/Indexing

Technical Item: Use of OWL Imports (Issue 119) (@@TODO mins)

All preparatory material for this agenda item is given at the following link: SkosDesign/Imports

Technical Item: Notations (Issue 79) (@@TODO mins)

Issues tracker: ISSUE-79

Jakob Voss has made a proposal for supporting notations, which uses skos:prefLabel and doesn't require any new vocabulary.

The only other proposal was made in 2006 by Alistair (see references). This proposal requires a skos:notation property.

Do we go with Jakob's proposal?

Dependencies: None


Discussion and comments:

Technical Item: Reference Semantic Relation Specialisations (Issue 56) (@@TODO mins)

@@TODO prepare this item.

Technical Item: Coordination (Issue 40) (@@TODO mins)

Issues tracker: ISSUE-40

This is a placeholder for any proposals or ideas which Ed/Clay would like to discuss.

There are rich seams of discussion on coordination and related issues on the list going back to 2006 and before, I'll try to capture a few links below but do search the list archives also. Try searching Google for "SKOS coordination" too :)



Discussion and comments (most recent first):

"Editorial" issues

Misc. issues

(Antoine) no will to classify them under a specific category now

"Open" SKOS Issues

(Antoine) Ideally someone should check the list of issues there to check whether one has been forgotten

Primer dependencies

SKOS schema and relationship to deprecated 2005 SKOS WD

Wednesday 14:30-16:00: Vocabulary management

The remaining schedule for VM is: publication of Working Draft on 1 June.

Thursday 2008-05-08