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

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?  

Cheers,

Al.

[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
Chilton
Didcot
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 Friday, 25 February 2005 18:00:05 UTC