W3C home > Mailing lists > Public > public-swd-wg@w3.org > October 2008

ISSUE-181 new draft response

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 22 Oct 2008 11:28:46 +0200
Message-ID: <48FEF24E.7000904@few.vu.nl>
To: SWD WG <public-swd-wg@w3.org>

Hi all,

Here's a new draft response to Michael on [ISSUE-181]. Please let me 
know what you think, especialy wrt. formality level!


Dear Michael,

Thank you for your comments [1]:

1. Non-assignable concepts
Classification systems usually contain objects that are, while not being
assignable concepts, nonetheless an integral part of the system (not
just a display/presentation device), e.g., number spans or - in case of
the DDC - so-called "centered entries":

T2-486-T2-488 Divisions of Sweden
333.7-333.9 Natural resources and energy
A centered entry represents a subject covered by a span of numbers.
Centered entries relate notationally coordinate classes together as a
single concept. For example, T2-485 represents Sweden; the centered
entry T2-486-T2-488 represents the geographic divisions of Sweden.
Centered entries are an important part of the structural hierarchy,
representing true broader concepts, even though this superordination is
not indicated by notation. In addition, as they often contain
instructions applicable to all subordinate classes, centered entries
cannot be modeled as a skos:Collection, since skos:Collection cannot be
part of the concept hierarchy (as defined in 9.6.4). A new class or
expanded skos:Collection class is required to allow concept collections
like spans or centered entries to be expressed as concepts.

If I understand your case correctly, your issue is caused by the 
constraint that states that instances of skos:Collection cannot be 
included in concept hierarchies. Otherwise you would just have been able 
to represent your "centered entities" as instances of this class.
But as you noted, we made the choice to clearly distinguish the 
definition of "groupings" from the one of "semantic networks", and your 
"centered entities" cannot be modelled as Collections [7].

Additionally, the heading of your comment "non-assignable concepts" 
hints that another solution would be possible, had we accepted the 
requirement R-IndexingAndNonIndexingConcepts [2] and proposed a solution 
to it. Indeed, I guess your "non-assignable" concepts can be likened to 
what we called "non-indexing concepts".
But as the requirement of having an indexing property in SKOS has been 
dropped in ISSUE-48 [3], we have dropped 
R-IndexingAndNonIndexingConcepts as well [4]. Note that this was not 
because the requirement you express is very rare, but because we would 
rather remain agnostic with respect to how SKOS entities are used (or 
not) in specific indexing situations, e.g. what property is used to index.

As a consequence of these problems having beeing already being 
extensively discussed, we propose to *close* ISSUE-181 [ISSUE-181], 
making no change to the existing SKOS documents. We hope that you are 
able to live with this.

Please note that it is however possible to coin a practice for 
representing centered entities as instances of skos:Concepts, provided 
you make your own (small) extension to SKOS. The SKOS Primer gives some 
general hints on the approach [5]. In your case, it is possible to make 
your own solution to R-IndexingAndNonIndexingConcepts. The following 
steps should be taken:
- first, identify an indexing property you want to use to assign 
concepts to other resources (e.g. dc:subject).
- second, define a subclass of skos:Concept, for instance 
my:NonAssignableConcept, which is defined as not being usable as the 
object of statements involving the chosen indexing property. This can be 
done in OWL, using a property inverse of the indexing property and an 
appropriate OWL cardinality constraint.

I hope this helps. Note that if you agreed with the practice proposed in 
the second part of this mail, or come with a better solution, we would 
encourage you to publish a brief best practice note and inform the SKOS 
community via the mailing list. We'd also be more than happy to set up a 
"SKOS community best practices" wiki page to collect links to such 
statements, similar to what has been done for [6].

Best regards,


[ISSUE-181] http://www.w3.org/2006/07/SWD/track/issues/181
[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Oct/0061.html
[2] http://www.w3.org/TR/SKOS-UCR#R-IndexingAndNonIndexingConcepts
[3] http://www.w3.org/2006/07/SWD/track/issues/48
[4] http://www.w3.org/2006/07/SWD/track/issues/46
[5] http://www.w3.org/TR/2008/WD-skos-primer-20080829/#secskosspecialization
[6] http://esw.w3.org/topic/SkosDev/ClassificationPubGuide?rev=12
[7] http://www.w3.org/2006/07/SWD/track/issues/33
Received on Wednesday, 22 October 2008 09:29:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:53 UTC