[Fwd: [SKOS] Issues Review

Hi all,

As I mentioned at the last telcon, I wrote a review last week of SKOS 
issues, with a suggestion for the top ten issues. At the time I didn't 
have a public email account, so I sent the email to the WG chairs and 
SKOS editors as a preview to help with telcon planning. I'm grateful to 
them for forwarding some sections to the WG, I should have asked them to 
forward the whole thing on my behalf. Anyway, here's the whole thing.

= SKOS Suggested Priorities =

This email reviews current SKOS issues. I discuss each issue in turn, in
order of decreasing importance (IMHO). Some proposed resolutions are
also given. Where I am issue owner, these should be taken as formal
proposals for the WG's consideration. Where I am not issue owner, or
where the issue is not yet open, these should be taken as suggestions to
the current or prospective issue owner.

== Top 10 Issues ==

Top 10 at a glance:

  1. [ISSUE-54] ConceptSemantics
  2. [ISSUE-67] StatingFormalDefinitions
  3. [ISSUE-48] IndexingRelationship / [ISSUE-77] SubjectIndexing
  4. [ISSUE-79] Notations
  5. [ISSUE-74] MappingPropertyConventions / [ISSUE-71]
ParallelMappingVocabulary
  6. [ISSUE-64] TextualDescriptionsForConcepts / [ISSUE-65] XMLLiteralNotes
  7. [ISSUE-68] RelatedIrreflexive / [ISSUE-69] BroaderIrreflexive /
[ISSUE-70] BroaderCycles
  8. [ISSUE-80] SKOS-OWL-Patterns
  9. [ISSUE-37] SkosSpecialization
  10. [ISSUE-41] UseLangTagsInExamples

----
[ISSUE-54] http://www.w3.org/2006/07/SWD/track/issues/54
ConceptSemantics (OPEN)

Quick fix? Yes.

This is probably most important, as it has to do with fundamental
aspects of the SKOS data model. Antoine has made a proposal [1] which I
suggest we vote on at the next telcon.

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0053.html

----
[ISSUE-67] http://www.w3.org/2006/07/SWD/track/issues/67
StatingFormalDefinitions (RAISED)

Quick fix? Yes.

This issue concerns the main body of the SKOS reference, and should
probably be opened and resolved ASAP.

N.B. This issue refers to a previous editors' draft of SKOS reference.
The current WD of the SKOS Reference attempts to resolve this issue by
adopting the style of prose used in the RDF schema specification (see [2]).

If Tom is satisfied that this style of prose addresses his original
concerns, then I suggest we consider the following proposal ASAP...

PROPOSED: To state formal aspects of the SKOS data model in the main
body of the SKOS reference as prose, following the style of prose used
in the RDF Schema specification. An OWL ontology will also be given as
an appendix to the SKOS reference.

I suggest we use this proposal to close ISSUE-67, then raise new issues
if there are any concerns with specific statements in the SKOS Reference.

[2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0129.html

----
[ISSUE-48] http://www.w3.org/2006/07/SWD/track/issues/48
IndexingRelationship (RAISED)
[ISSUE-77] http://www.w3.org/2006/07/SWD/track/issues/77 SubjectIndexing
(RAISED)

Quick fix? Maybe.

The main application of SKOS will be for subject indexing, therefore we
should have a clear picture for how this is supported by SKOS and/or
other vocabularies. I suggest both of these issues be opened ASAP.

These two issues are closely related, with a subtle difference.
[ISSUE-48] states the requirement for a subject indexing property, from
the SKOS use cases. [ISSUE-77] asks what are we going to do about the
four subject indexing properties that were in previous drafts, but
aren't in the current SKOS Reference WD (skos:subject,
skos:primarySubject, and their inverses).

If we consider [ISSUE-48] alone, then the basic requirement as stated is
clearly met by the dc:subject property. Therefore we have no need for
skos:subject or skos:isSubjectOf.

However, [ISSUE-77] also concerns skos:primarySubject, which meets a
more specific requirement going beyond that stated in [ISSUE-48].
skos:primarySubject was originally introduced to express the stronger
statement made when one and only one concept from a KOS (typically a
classification scheme) is used to index a document [3].

Note also that skos:subject is deployed in some applications, e.g.
DBpedia [4].

However, Guus has previously suggested that providing vocabulary for
subject indexing should be out of scope for SKOS.

Although I am sensitive to Guus' view, I am reluctant to make changes
which would hurt deployed applications. Also, the semantics of
skos:subject & skos:primarySubject are straightforward and don't
interact in any serious way with other parts of the SKOS data model.
Given this, once these issues are opened, I suggest we consider the
following proposal ASAP...

PROPOSED: To include skos:subject, skos:primarySubject, skos:isSubjectOf
and skos:isPrimarySubjectOf in the SKOS vocabulary, and to add a new
section to the SKOS Reference defining the data model for this
vocabulary, following the original data model stated in the SKOS Core
Vocabulary Specification 5 November 2005 without any modification.

Accepting this proposal should be enough to close both [ISSUE-48] and
[ISSUE-77].

[3] http://www.w3.org/2001/sw/Europe/reports/thes/8.5/
[4] http://wiki.dbpedia.org/Datasets?v=1ec1#h18-7

----
[ISSUE-79] http://www.w3.org/2006/07/SWD/track/issues/79 Notations (RAISED)

Quick fix? Yes.

Notations are an important feature for some KOS, therefore I suggest we
open this ASAP and consider proposals.

Note also that a suggestion has been made for a usage convention which
doesn't require any new URIs in the SKOS vocabulary [5]. This looks ok
to me, so once the issue is opened, I suggest the WG consider the
following proposal:

PROPOSED: To add new sub-sections to the SKOS Reference and Primer
illustrating a recommended usage convention for notations as specified
in http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0211.html

[5] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0211.html

----
[ISSUE-74] http://www.w3.org/2006/07/SWD/track/issues/74
MappingPropertyConventions (RAISED)
[ISSUE-71] http://www.w3.org/2006/07/SWD/track/issues/71
ParallelMappingVocabulary (RAISED)

Quick fix? No.

[ISSUE-74] asks, what are the usage conventions for SKOS mapping
properties and SKOS semantic relation properties? [ISSUE-71] asks, do we
need the properties skos:broadMatch, skos:narrowMatch and
skos:relatedMatch at all?

These two issues go right to the heart of recommended usage for SKOS
semantic relation and mapping properties. They are intimately related,
as usage conventions for mapping properties depend on vocabulary
available, and vice versa. I suggest we open these ASAP, to give time
for preparation and due consideration of alternatives.

To give a little background, the current SKOS Reference WD assumes that
the main reason for having a "parallel" vocabularies for
broader/narrower/related is to provide a convenient mechanism for
distinguishing links between concepts within the *same* scheme from
links between concepts in *different* schemes. This utility obviously
depends on certain usage conventions being followed, i.e. that
skos:broader, skos:narrower and skos:related are *only* used to link
concepts in the same scheme, and that skos:broadMatch, skos:narrowMatch
and skos:relatedMatch are *only* used to link concepts in different
schemes. To restate the point, if these usage conventions aren't
followed, then the main raison d'etre for skos:broadMatch,
skos:narrowMatch and skos:relatedMatch falls apart.

Note that [ISSUE-73] and [ISSUE-75] are both dependent on [ISSUE-71].
[ISSUE-73] asks, which other properties is skos:exactMatch disjoint
with? [ISSUE-75] asks, which other properties can be involved in
property chain inclusions with skos:exactMatch? Both of these questions
depend on the SKOS vocabulary recommended for mapping.

Note also that [ISSUE-83] is closely related to [ISSUE-71] and
[ISSUE-74], because the proposed inference pattern depends on usage
conventions which are not yet established. However, I suggest we
consider [ISSUE-83] separately as a lower priority, because the proposed
inference pattern can probably not be supported, regardless of our
decision on [ISSUE-74].

[ISSUE-73] http://www.w3.org/2006/07/SWD/track/issues/73
[ISSUE-75] http://www.w3.org/2006/07/SWD/track/issues/75
[ISSUE-83] http://www.w3.org/2006/07/SWD/track/issues/83

----
[ISSUE-64] http://www.w3.org/2006/07/SWD/track/issues/64
TextualDescriptionsForConcepts (RAISED)
[ISSUE-65] http://www.w3.org/2006/07/SWD/track/issues/65 XMLLiteralNotes
(RAISED)

Quick fix? Maybe.

[ISSUE-64] asks whether the three recommended patterns for use with SKOS
documentation properties are still appropriate. [ISSUE-65] asks more
specifically, what is the recommended pattern for giving different types
of XML content as documentation.

These two issues concern the SKOS documentation properties
(skos:definition etc.) which are a key part of the model. We should at
least open [ISSUE-64] and review the usage patterns for these properties
ASAP.

Given that SKOS is an OWL Full ontology, I can see no compelling reasons
for restricting usage to any one or two of these patterns. In this case
it would seam reasonable, at this stage, to keep SKOS flexible, and to
allow communities of practice to extend or restrict their practice as
needed. Therefore, I suggest the following...

PROPOSED: To keep the domain, range and type of the SKOS documentation
properties as specified in the SKOS Reference 25 Jan 2008 WD, and to
describe in both SKOS Reference and SKOS Primer three alternative
patterns for their usage (as originally specified in the SKOS Core Guide
2 Nov 2005).

[ISSUE-65] of course depends in part on the resolution of [ISSUE-64]. If
we resolve [ISSUE-64] as above, then we could drop or postpone
[ISSUE-65] as out of scope for the current WG. I think it would be
entirely reasonable to give responsibility for resolving [ISSUE-65] to
the community and/or subsequent working groups.

Therefore..

PROPOSED: To postpone [ISSUE-65] as out of scope for the current WG.

----
[ISSUE-68] http://www.w3.org/2006/07/SWD/track/issues/68
RelatedIrreflexive (RAISED)
[ISSUE-69] http://www.w3.org/2006/07/SWD/track/issues/69
BroaderIrreflexive (RAISED)
[ISSUE-70] http://www.w3.org/2006/07/SWD/track/issues/70 BroaderCycles
(RAISED)

Quick fix? Maybe.

I've grouped these three issues together because I think 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. These are
fairly importatn issues concerning how the SKOS semantic relation
properties are used, therefore I suggest we open them for consideration
ASAP.

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 all thesauri, classification schemes and
taxonomies I know of adhere to.

If we favour a weaker data model, then we answer no to all three. The
advantage is flexibility, which *might* prove advantageous when
exploring certain patterns for using SKOS and OWL together. However,
these patterns are less than clear at the moment, and clearly the
primary use cases for using SKOS alone are better served with a stronger
model.

Therefore...

PROPOSED: skos:related and skos:broaderTransitive are both irreflexive.

----
[ISSUE-80] http://www.w3.org/2006/07/SWD/track/issues/80
SKOS-OWL-Patterns (RAISED)

Quick fix? No.

This issue asks, what are the recommended patterns for working with SKOS
and OWL in combination? This is known to be a requirement, therefore I
suggest we open this issue ASAP.

We have some discussion pieces on this already, and a placeholder in the
SKOS Reference for an appendix on this. I suggest the document editor's
develop sections for both SKOS Reference and SKOS Primer on this, and
request a discussion on them at the next available opportunity.

----
[ISSUE-37] SkosSpecialization

Quick fix? No.

This issue asks, what are the recommended patterns for extending SKOS?
Extensibility is an important requirement, therefore I suggest we open
this ASAP.

As above for [ISSUE-80], we have some content on this already. I suggest
the document editor's develop sections for both SKOS Reference and SKOS
Primer on this, and request a discussion on them at the next available
opportunity.

----
[ISSUE-41] UseLangTagsInExamples

Quick fix? Yes.

This is resolved, all that remains is for me to send a message to Jeremy.

== Other Issues ==

Here's a prioritised list of the remaining issues, with some brief notes.

  11. ISSUE-27 AnnotationOnLabel -- possibly out of scope, if labels as
resources can be defined as a 3rd party extension, and domain of
documentation properties is left open.
  12. ISSUE-26 RelationshipsBetweenLabels -- our tentative resolution is
implemented in the SKOS Reference. Any further work on this issue
depends on public comment.
  13. ISSUE-75 ExactMatchInclusions -- depends on resolution of 71/74.
  14. ISSUE-73 ExactMatchDisjoints) -- depends on resolution of 71/74.
  15. ISSUE-72 ExactMatchTransitive -- this is about drawing inferences
across multiple mappings, which we don't have any use cases for, but
which is interesting.
  16. ISSUE-40 ConceptCoordination -- interesting to consider if we have
time but could probably postpone.
  17. ISSUE-45 NaryLinksBetweenDescriptorsAndNonDescriptors) -- could be
solved as a 3rd party extension.
  18. ISSUE-56 ReferenceSemanticRelationshipSpecializations) -- I
suggest drop the extensions as out of scope.
  19. ISSUE-46 IndexingAndNonIndexingConcepts -- needs clarification,
are we only considering "qualifiers", or also other examples of
"non-indexing" concepts?
  20. ISSUE-47 MappingProvenanceInformation -- suggest resolve as per
concept scheme containment.
  21. ISSUE-83 SemanticsOfSchemeContainmentProperties -- this inference
is unlikely to be supported.
  22. ISSUE-84 ConstructionOfSystematicDisplaysFromGroupings) --
important, but arguably out of scope.
  23. ISSUE-76 SymbolicLabels -- could be dropped or postponed, no
supporting use cases.
  24. ISSUE-78 SubjectIndicators -- could be dropped or postponed, not
our problem.
  25. ISSUE-50 CompatibilityWithDC -- this is a general requirement. I
suggest we drop this issue, and request comments from DC-ARCHITECTURE
WG, then raise any issues if specific incompatibilities are found.
  26. ISSUE-51 CompatibilityWithISO11179 -- could deal with as per issue
50 above.
  27. ISSUE-52 CompatibilityWithISO2788 -- very hard to define
compatibility here. Suggest we drop and raise new issues if specific
points of incompatibility are found.
  28. ISSUE-53 CompatibilityWithISO5964 -- as per issue 52.
  29. ISSUE-49 LexicalMappingLinks -- arguably out of scope, suggest we
postpone.
  30. ISSUE-81 LabelRelationsNaming -- I suggest we don't waste any time
on discussion of naming, there are two many important issues of
functionality to consider first, and supporting documentation should
resolve any possible confusion. If it must be considered, then put it
straight to a vote, then go with that.
  31. ISSUE-82 PropertyNames -- as per issue 81.

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Friday, 22 February 2008 05:44:32 UTC