- 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>
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..) regards, benjamin -- Benjamin Nowack Kruppstr. 100 45145 Essen, Germany http://www.bnode.org/ > >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 Saturday, 26 February 2005 16:34:15 UTC