W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2005

Re: SKOS Core review Re: issue: non-Literal "comment" properties Re: new draft of SKOS Core guide

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Fri, 25 Feb 2005 18:28:15 +0100
To: Thomas Baker <thomas.baker@bi.fhg.de>
Cc: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org
Message-ID: <PM-EH.20050225182815.65794.1.1D@>

On 25.02.2005 16:23:21, Thomas Baker wrote:
>On Fri, Feb 25, 2005 at 03:36:30PM +0100, Benjamin Nowack wrote:
>> Just some food for thought:
>> I know that it's perfectly legal in non-DL RDFS space to
>> have hybrid properties, but given that e.g. dc:creator
>> has already caused a lot of confusion and needs rules
>> or application-specific extensions to be processed
>> without problems, wouldn't it make sense to separate
>> datatype props from object props or to limit certain
>> documentation props to literals? 


>The Abstract Model says that the value of a DCMI metadata term
>is by definition a resource, even if the representation of
>that resource is in some encodings limited to a string value.
>The Abstract Model work was itself a response to confusion in
>the implementor communities -- confusion that was determined
>in large part by the possibilities of different implementation
>In the course of untangling these issues, we have ended
>up in the DCMI Usage Board with a bias against building
>implementation-related restrictions into the very definitions
>of the vocabulary.  Limiting values to literals, for example,
>can perhaps more appropriately be done in some sort of
>application-profile construct rather than "once and for all"
>in the canonical representation of the vocabulary.
hm, not sure if I'd completely agree here. (To me) the
semantic web is all about formally describing stuff so that
machines can as un-fuzzy as possible process it. why did the
webont WG invent owl:DatatypeProperty and owl:ObjectProperty,
if we then keep on describing the semantics of a property in
an (only human-readable) abstract model document? I understand
that certain encodings can limit serialization options, but
on the rdf level, I'd try to avoid being ambiguous.
I may well be wrong, and DCMI definitely has an unbeatable
experience in this area, so, hey. but out of curiosity:
as a SWBPD vocab management TF coordinator, would you
actually encourage vocab developers to invent hybrid
properties (yep, by "hybrid" I meant plain rdf:Properties
which don't constrain their range to either literals or
non-literals)? I guess that'll be another "it depends"
answer ;)
Not sure about the SKOS case either. I agree that having
16 (or 24, as SKOS allows three interpretations of a doc
prop) different documentation properties is nothing I'd
be happy about to implement. Implementation-wise, though,
having been able to use sub-properties of rdfs:comment
for more specific term notes was really nice. however,
as has already been said, tweaks to term/concept browsers
seem to be neccessary either way...) 

looking forward to seeing the skos spec/guide published!


Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany

>[1] http://dublincore.org/documents/abstract-model/
>Dr. Thomas Baker                        Thomas.Baker@izb.fraunhofer.de
>Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
>Fraunhofer-Gesellschaft                          work +49-30-8109-9027
>53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
>Personal email: thbaker79@alumni.amherst.edu
Received on Friday, 25 February 2005 17:28:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:05 UTC