- From: Svensson, Lars <svensson@dbf.ddb.de>
- Date: Wed, 15 Feb 2006 09:46:27 +0100
- To: "Antoine Isaac" <Antoine.Isaac@KB.nl>, <public-esw-thes@w3.org>
In litteris suis de Dienstag, 14. Februar 2006 18:17, public-esw-thes-request@w3.org <mailto:public-esw-thes-request@w3.org> scripsit: > Dear all, > > In the project I work for we have made a conversion of the IconClass > classification scheme (www.iconclass.nl) to SKOS. That raised a lot > of problems, but not the one of notations. ;-) That's good to hear! > > Notations (such as 25F) are indeed the only things that are supposed > to be used to classify the documents. There is a text attached to > them (e.g., 'animals'), but this text, though very important (it > gives the natural meaning of the subject) will never be used as the > real descriptor for images. We had therefore something very > comparable to the prefLabel/altLabel distinction. Can you explain exactly how you solved the problem? > > I think this is a similar case to Lars' one. And from this > experience, I would share Andrew's analysis on DDC [1]. Or favor a > solution like Mark's one [2], if you really don't want to use > prefLabel directly (but then you've got to be sure the loss of > genericity/interoperability of your solution is compensated by the > added value of using such a specialisation in your system!) > > > Also a few thoughts about Alistair's proposal [3]. In principle a > proposal for such a new property is interesting, but one should be > sure it will be adequately understood and used. > >>>>> - The main purpose of the property is to provide a human-friendly > identifier for the concept, whose value is not a recognisable word or > collocation of words from any natural language. > > That can grasp the intended meaning of the notation property, but are > you sure that people will not fly away from such a specification ;-) > ? Indeed it is a bit intimidating... > >>>>> - The value should be a typed literal, where the datatype >>>>> defines both > the scope of reference, and the lexical space of allowed values. > > Ok, and that could be a nice added value of such a property. > But beware that people do not waste thinking too much about > specifying the acceptable notations: IconClass for example allows > only for one or two letters in a notation, in a way that is not > easily specifiable even using regular formulas. > The effect would be even worse if designers realize at the end that > that was not really useful, or worse, is now preventing them to use > standard tools that will work with prefLabel. Perhaps this is similar > to Stella's final argument in [4]. Summing the discussion up, I'd say that Alistair's proposal [1] (thanks a lot, Alistair! You described it the way I would have done it) would probably not reach the necessary consensus. The question of course remains, how to handle this. What would you all say to the invention a new property skos:notation as a subproperty of both skos:prefLabel and dc:identifier? This way we could keep the prefLabel unique as stated in the skos vocabulary specification [2]. Remains what to do with the caption. Here I'm eager to hear your input. A completely new property, just skos:altLabel, or a skos:caption as a subproperty of skos:altLabel? Cheers and thanks for your interest! Lars [1] http://lists.w3.org/Archives/Public/public-esw-thes/2006Feb/0035.html [2] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/#prefLabel -- Dr. Lars G. Svensson Die Deutsche Bibliothek Informationstechnik / Projekt DDC-Deutsch Tel.: 069 / 1525 - 1752 http://www.ddc-deutsch.de
Received on Wednesday, 15 February 2006 08:46:37 UTC