- From: Natasha Noy <noy@SMI.Stanford.EDU>
- Date: Thu, 3 Jun 2004 23:41:12 -0700
- To: "McBride, Brian" <brian.mcbride@hp.com>
- Cc: SWBPD list <public-swbp-wg@w3.org>
Brian, Thank you for doing a pass over the document -- indeed, it is much clearer what you had in mind and puts a slightly different slant on the document. I am perfectly comfortable with and in fact very much like the way you included RDFS in it. I've re-worked the preamble, basically taking most of your text. In fact, I've also added some text (partly based on Alan's message [1]) to discuss the whole sw scenario, whether or not you own the terminology, etc. Some of that has made it into considerations, in particular for approach 2. Thank you for pushing the note along those lines! There are two things I am much less comfortable with in your approach: (1) your example and (2) the recommendation of a particular approach for converting to OWL DL. On the example, while I am not attached to the subjects example and would be happy to change it, I think your particular example creates more confusion (at least to me) than it resolves. The fact that you need to go to some length to explain the domain of your example is not a very good sign (and even then I had some question about what is a ticket). Besides, in my experience, many people have trouble with figuring out whether a particular printer model (HP LaserJet 8100) is a class or an instance, and somehow fewer have trouble with "Lenny the Lion". It seems that introducing this extra level of complexity here doesn't seem to help. However, any other suggestions on this front are welcome. More important, I am really uncomfortable with recommending one particular approach. You chose approach 3 and, for example, Alan, is a staunch proponent of 4, and there was a message just this week on the list [2] and another message from someone else after an earlier draft saying that after considering all the trade-offs, they chose 2, and that I had some private email indicating that in some cases, [5] would be most practical. All these are sure signs that we are not yet in the position to choose just one solution as a recommended one. Not for classes as values, at least. I am not saying that this is the case for every pattern, but for the moment I believe it is certainly the case for this one. Perhaps, as we get more experience on how things are actually used on the SW, we could rule out some of the approaches later. Furthermore, if I am a web designer and decide to follow your recommendation, what do I do if there are no tools to do the conversion for me (which is the case today)? Your text is based on the assumption that the tools are there or are going to be there right away. I am not sure this is the case. Thus, I've listed providing a specific recommendation it as an open issue and let's see what others think. That said, I think you are making a very good point that providing a more specific guidance for *tool developers* in terms of how to do a conversion from one approach (in particular, 1) to another, is important. I think there are in fact two audiences for the patterns: (1) ontology designers who use the available tools to model their ontologies and (2) tool developers who will (hopefully) build tools to convert between patterns seamlessly and allow the most natural approach to modeling for the first group while doing the conversion behind the scenes. So, I am wondering if it would be worthwhile having an appendix aimed specifically at tool developers that gives more precise guidance on the conversion? On the other hand, it seems that a tool developer should be able to figure it out from the rest of the note? It seems that the conversion itself is straightforward. Natasha [1] http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0124.html [2] http://lists.w3.org/Archives/Public/public-swbp-wg/2004Jun/0000.html On May 31, 2004, at 9:18 AM, McBride, Brian wrote: > I've had a go at expressing the ideas I had about a different spin for > this > document. The words aren't flowing very freely, and the graphics > certainly > are not, but I hope there is enough here for folks to see where I'm > headed > and come to a view as to whether it is worthwhile. > > I've taken a few liberties with the text, for which I hope Natasha will > forgive me. I don't feel strongly about these, they are just > illustrative. > > However, it is worth reading the abstract and the introduction to get > an > idea of how I'm suggesting reframing the purpose of the document. > > Thinking of the task in this way, led me to the the key claim I am > making, > that we can automatically translate between the natural approach using > classes as values and the (I think) preferred approach for OWL DL. > > Thus I am suggesting: > > 1) We should define properties that describe the relationship between > the > RDFS and DL approaches. > > 2) We should recommend an approach, so that folks who just want a quick > answer to "How should I do ..." don't have to work too hard > > 3) More controversially, we should recommend in general, the classes as > values approach on the grounds of simplicity, suggesting automatic > transformation to a form suitable for processing by a DL reasoner if > that is > required. > > I am filling sandbags as you read this. > > When unzipped, you want the *-bwm-v5 version of the document. > > Brian > > <ClassesAsValues.zip> Natasha
Received on Friday, 4 June 2004 02:41:21 UTC