- From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
- Date: Fri, 25 Feb 2005 17:59:33 -0000
- To: "Benjamin Nowack" <bnowack@appmosphere.com>
- Cc: <public-esw-thes@w3.org>
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