RE: ISSUE-135: Last Call Comment: rdfs:label

>-----Original Message-----
>From: Alistair Miles [mailto:alistair.miles@zoo.ox.ac.uk]
>Sent: Tuesday, December 09, 2008 5:02 PM
>To: Michael Schneider
>Cc: public-swd-wg@w3.org
>Subject: Re: ISSUE-135: Last Call Comment: rdfs:label
>
>Hi Michael,
>
>On Thu, Dec 04, 2008 at 06:28:38PM +0100, Michael Schneider wrote:
>> Alistair Miles wrote:
>>
>> >The Working Group thus propose to change the type of the SKOS
>> >labelling properties to owl:AnnotationProperty, and *postpone* this
>> >issue (indicating that it may merit further consideration in the
>> >future). Can you live with this?
>>
>> I think that closing this issue as /postponed/ does not make much
>sense. A future WG will have no real option to remove the connection
>from rdfs:Label without largely breaking backwards compatibility. So I
>suggest to close the issue as
>> resolved, eventually.
>>
>> But my concern is more on the chosen design, not so much on whether
>there is a problem with OWL DL. It looks to me that SKOS generally
>provides for the different kinds of properties a small, shallow property
>hierarchy, having some SKOS property as their upper property. For
>example, there is the idea of "notes", and therefore there is a general
>property "skos:note", having all concrete kinds of SKOS notes below.
>This pretty well represents the notion of having "several kinds of SKOS
>notes, namely editorial notes (skos:editorialNote), change notes
>(skos:changeNote), etc. But for labels, there is no general SKOS label,
>but all concrete kinds of labels directly inherit from rdfs:label. This
>looks like a hack to me.
>
>Well, the idea was indeed to have a shallow property hierarchy for
>labeling properties, but as rdfs:label seemed a suitable property to
>act as the general parent of other labeling properties, we thought it
>better to re-use existing vocabulary rather than invent new, possibly
>redundant, terms.
>
>In the case of skos:note, there was no suitable term from another
>vocabulary to act as a general note property, so we coined skos:note.
>>
>> My proposal is to introduce a skos:label property, being a sub
>property of rdfs:label, and all concrete label properties are sub
>properties of skos:label. Semantically, nothing would be changed by
>this. In particular all current kinds of SKOS labels would still be
>rdfs:label's. But one then don't has to refer to RDFS labels, i.e. go
>outside of SKOS, if one wants to generally talk about labels in SKOS.
>>
>
>I don't see what you gain by this. If rdfs:label and skos:label are
>effectively equivalent, why not just use rdfs:label?

Not equivalent. skos:label would be a specialization of rdfs:label. (I don't think
everyone would be happy to learn that every instance of rdfs:label is also
a skos:label.) 

>Btw others have suggested a general skos:label property, see e.g. [1],
>but I'm still not clear on what the benefit would be.

Technically/semantically there is no benefit, of course. But I would, in general, prefer to keep the basic vocabularies of the Semantic Web as self-contained as possible. If the idea was to have a common base property for all concrete SKOS labels, then I would prefer to have this base property in the SKOS namespace itself. It is then possible to talk about SKOS labels in general without the requirement to go beyond SKOS, unless I am explicitly interested in the /additional/ relationship to rdfs:label. 

If I think in terms of a "general SKOS label", then it is most natural to me to also have a general SKOS label /within/ the SKOS language, not borrowed from some other vocabulary, which happens to "already exist somewhere". For me, it seems that the reason to reuse rdfs:label is mostly to "connect" to the rest of the SemWeb. That's a good reason, but IMHO this practical aspect doesn't justify to change the basic language model. 

You may say that substituting skos:label by rdfs:label doesn't change the model (being a shallow hierarchy after all), but I think it brings at least some confusion: There isn't then actually a general SKOS label anymore, just a substitute taken from a (very!) different language, which happens to have a similar name. And I expect this will bring up questions by people trying to learn SKOS, and it will need to be explained again and again. But putting rdfs:label on top of skos:label looks less critical to me, since then hardly anyone needs to refer to rdfs:label anymore, if he only wants to talk about SKOS labels in general.
 
>In your original comment, you say "If no strong reasons talk against,
>I suggest to /not/ have sub properties of rdfs:label." However if we
>follow your suggestion we still end up with a sub-property of
>rdfs:label.

Yes, because the situation has changed since then. At that time, I wasn't sure that this is really your intention. Now that I know that it /is/ your intention, I won't ask you anymore to change this. And changing the type of the SKOS properties to annotation properties seems to me a reasonable decision (just to answer your original question). But from a modeling perspective, I would prefer to put a skos:label (also an annotation property, of course) between the concrete labels of SKOS and rdfs:label. This would mean that you do /not/ need to revert your decision. 

But this will be your decision in the end. I think I am running out of arguments eventually. :)

>Thanks,
>
>Alistair
>
>[1] http://lists.w3.org/Archives/Public/semantic-web/2008Jul/0404.html

Regards,
Michael

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus

Received on Wednesday, 10 December 2008 20:43:01 UTC