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

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

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Sat, 26 Feb 2005 17:33:48 +0100
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
Cc: <public-esw-thes@w3.org>
Message-ID: <PM-EH.20050226173348.B3E38.1.1D@>

On 25.02.2005 17:59:33, Miles, AJ \(Alistair\) wrote:
>Hi benjamin,
>I'm not sure what to say about this at the moment.  I had thought about typing
>all the properties (or as many as possible) in SKOS Core as either
>owl:ObjectProperty or owl:DatatypeProperty as appropriate, but nobody has
>asked for that yet so I've left it for the moment.
>I think that the primary use cases we're trying to satisfy are really very
>simple, and so making SKOS data sets 'reasonable' hasn't been a priority.
>Bernard's example of defining classes of concept in relation to restrictions
>on scheme membership (see [1]) is one concrete use case I have right now that
>benefits from being able to do DL reasoning, another is defining disjoint
>classes of concept to represent fundamental facets (see [2] from earlier draft
>of SKOS Core Guide).  Do you have any other scenarios?  
No, not really. I'm using a home-grown framework and I personally don't
even see so much space for (OWL) DL-restricted tools w.r.t real-world
RDF data, as e.g. inverse functional datatype properties or the
unrestricted use of rdf:Properties simply have too much utility.
I justed wanted to point out that processing typed rdf properties (and
having precise domain and range definitions) is easier for generic
implementations than having to guess how a piece of rdf should be
interpreted. My use cases are around the generation of editing and
search forms and the creation of browsing front-ends for OWL/RDFS
term sets and SKOS concept schemes. I'm also trying to build
support for SKOS doc props into an OWL editor. So this is more of
an implementation feedback than a proper idea how to best model
SKOS documentation properties. (The only suggestions I'd have
would be to consider dropping skos:publicNote and skos:privateNote.
Publication constraints will imho be handled on an application level,
at least the "public" flag is sort of a default for doc props. A handy
addition would be a common super-property skos:documentation or
skos:note you already mentioned. Perhaps with rdfs:comment as a
sub-property for facilitated querying/display..)


Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany

>[1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Feb/0063.html
>[2] http://www.w3.org/2004/02/skos/core/guide/2004-11-25.html#secexttype
>Alistair Miles
>Research Associate
>CCLRC - Rutherford Appleton Laboratory
>Building R1 Room 1.60
>Fermi Avenue
>Oxfordshire OX11 0QX
>United Kingdom
>Email:        a.j.miles@rl.ac.uk
>Tel: +44 (0)1235 445440
>> -----Original Message-----
>> From: Benjamin Nowack [mailto:bnowack@appmosphere.com]
>> Sent: 25 February 2005 17:28
>> To: Thomas Baker
>> Cc: Miles, AJ (Alistair); public-esw-thes@w3.org
>> Subject: Re: SKOS Core review Re: issue: non-Literal "comment"
>> propertiesRe: new draft of SKOS Core guide
>> On 25.02.2005 16:23:21, Thomas Baker wrote:
>> >
>> >Benjamin,
>> >
>> >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
>> >scenarios.
>> >
>> >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!
>> regards,
>> benjamin
>> --
>> Benjamin Nowack
>> Kruppstr. 100
>> 45145 Essen, Germany
>> http://www.bnode.org/
>> >Tom
>> >
>> >[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 Saturday, 26 February 2005 16:34:15 UTC

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