- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Wed, 27 May 2009 08:44:34 +0100
- To: Jim Hendler <hendler@cs.rpi.edu>
- Cc: Jie Bao <baojie@gmail.com>, Bijan Parsia <bparsia@cs.manchester.ac.uk>, Michael Schneider <schneid@fzi.de>, "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
I wasn't trying to be difficult -- I was trying to make QRG better and hence more widely usable. Anyway, I agree that this is a relatively minor issue and I won't say any more about it. Ian On 27 May 2009, at 00:51, Jim Hendler wrote: > Jie has suggested adding 4 lines to the document, not a major > section - this would still be quick, but would be important to the > OWL/RDF community who need to know some terms are not being used > anymore - I think that group also wants/need QUICK -- if you are > worried about size, we could always go back to the version that > didn't include the structural syntax :-) Seriously, this document > serves a number of purposes, and JIe's very small addition of > section 4.2 seems not to get in the way and to be needed by the > constituencies we care about --- JH > > On May 25, 2009, at 6:11 AM, Ian Horrocks wrote: > >> Jie, >> >> You still seem to labour under the misapprehension that the goal >> of QRG is to provide a *comprehensive* reference. On the contrary, >> the goal is to provide a *QUICK* reference (the name gives a hint >> on this). >> >> There will always be some tension between speed and >> comprehensiveness. In almost all useful examples of quick >> references that I have seen/used comprehensiveness is deliberately >> sacrificed in favour of ease of use. The target audience is people >> who are not very familiar with the language and who often need to >> remind themselves of its syntax. Such people typically won't use >> the more esoteric parts of the language -- they just need an easy >> to use cheat-sheet covering the most commonly used features. >> Remember when you were first learning a language? Your tool of >> choice was no doubt some relatively short list of common words -- >> not the 20 volume OED. >> >> Ian >> >> >> >> On 22 May 2009, at 18:20, Jie Bao wrote: >> >>> On Fri, May 22, 2009 at 5:13 AM, Ian Horrocks >>> <ian.horrocks@comlab.ox.ac.uk> wrote: >>>> I must say that I am in full agreement with Bijan here -- adding >>>> distinguishing marks would be going backwards. >>>> >>> Same Here >>> >>>> To be honest, I am baffled by the notion that deprecated >>>> vocabulary should >>>> occur in the QRG *at all*. The main target audience of QRG is >>>> surely people >>>> creating OWL 2 documents who need a quick reminder of the syntax >>>> of the the >>>> construction they are trying to use. Offering them the >>>> possibility to use >>>> deprecated vocabulary is *not* useful. >>>> >>> Before considering adding those vocabulary, I also thought they are >>> "deprecated". However, I was warned that only owl:DataRange is >>> officially deprecated [1]. For owl:DeprecatedClass and >>> owl:DeprecatedProperty, there have been quite a lot of discussion >>> that >>> they are *not* deprecated [5]; this is similar to >>> owl:distinctMembers >>> (but I don't find the record). >>> >>> For owl:OntologyProperty, since a lot of discussion was pre-date my >>> joining to the WG, I'm not sure about its status, but from the >>> record >>> of Issue-91 [3] and the lack of an official vote on its >>> deprecation, I >>> believe it should not be treated as a deprecated vocabulary either. >>> Issue-91 actually was solved with action 82 "Edit the >>> specification to >>> mention the well-known ontology properties in the spirit of OWL >>> 1.0", >>> I don't remember when this was changed to completely remove >>> "ontology >>> property" from the structural definition (and other user-facing >>> documents) and only mention it in the RDF semantics. >>> >>> There have been argument on what is deprecation of XXX, e.g. [2] >>> defines it to be >>> - no mapping rule from the functional syntax to XXX is given >>> - a mapping rule the other way is specified >>> >>> However, as far as I know, the WG has never come to the conclusion >>> that this is an official definition of deprecation, and have came >>> to a >>> formal vote on the list of deprecated vocabulary. >>> >>> [1] http://www.w3.org/2007/OWL/tracker/issues/29 Issue 29 >>> (owl:DataRange) >>> [2] http://lists.w3.org/Archives/Public/public-owl-wg/2008Jan/ >>> 0163.html >>> Jeremy Carroll on the definition of "deprecation" >>> [3] http://www.w3.org/2007/OWL/tracker/issues/91 >>> [4] http://www.w3.org/2007/OWL/tracker/actions/82 >>> [5] http://www.w3.org/2007/OWL/tracker/issues/90 >>> >>>> Finally, with this kind of card it is definitely the case that >>>> "less is >>>> more". Adding irrelevant or obscure material to the card will >>>> make it harder >>>> to use and eventually useless. >>>> >>> That's true in general (and that's why I gave up adding a few other >>> RDF vocabulary), but I wonder if the 5 terms mentioned in the >>> section >>> meet this criteria: they have been a part of the OWL 1 >>> vocabulary, are >>> not officially deprecated except for owl:DataRange, and are >>> supported >>> by all existing OWL tools which means many ontologies produced from >>> these tools will still use them, even for years to come. And since >>> they are still OWL 2 Full features, they are actually relevant >>> part of >>> the languages thus may deserve some proper documentation in QRG. >>> >>> Jie >>> >>>> Ian >>>> >>>> >>>> >>>> >>>> >>>> On 21 May 2009, at 21:48, Bijan Parsia wrote: >>>> >>>>> On 21 May 2009, at 20:36, Jie Bao wrote: >>>>> >>>>>> On Wed, May 20, 2009 at 4:21 PM, Michael Schneider >>>>>> <schneid@fzi.de> >>>>>> wrote: >>>>> >>>>> [snip] >>>>>>> >>>>>>> Well, since I am asked... >>>>>>> >>>>>>> What would I expect from such a card (I admit that I did not >>>>>>> ponder much >>>>>>> about QRG in the past)? Thinking more generally, what I would >>>>>>> expect >>>>>>> from >>>>>>> other languages (a card for HTML for example), yes, I think >>>>>>> as long as >>>>>>> it is >>>>>>> technically possible (enough space on the card), I would want >>>>>>> to have >>>>>>> /all/ >>>>>>> language features mentioned on it, even if they are "rarely >>>>>>> used", >>>>>>> "legacy" >>>>>>> or even "deprecated". >>>>>> >>>>>> I agree >>>>> >>>>> Frankly, neither of you are reasonable members of the target >>>>> audience. >>>>> >>>>> It also seems like Michael at least just hasn't used such >>>>> cards. I'm not >>>>> sure how useful it is to engage in imaginings at this point. >>>>> >>>>>>> Because it is quite possible that I want to / have to use >>>>>>> this card when >>>>>>> working with old ontologies. >>>>> >>>>> You never have to use the card. And if you are using old >>>>> ontologies I >>>>> would recommend using a card for that language. >>>>> >>>>> Even in the ideal case, I think having extra cruft is a problem >>>>> (since >>>>> it's typically a distraction). But when you are trading off >>>>> things like font >>>>> size, etc. it's really silly. >>>>> >>>>>>> I wouldn't really want to have the "special" >>>>>>> features in a separate section, but rather along with the >>>>>>> other features >>>>>>> belonging to the same category. But I would appreciate if >>>>>>> there were a >>>>>>> *small* marker placed nearby a feature telling what's special >>>>>>> with them. >>>>> >>>>> Michael, perhaps you forgot the length discussion in the >>>>> telecon why even >>>>> a small "new" is bad design. Here's why: Distinguishing marks >>>>> *draw the eye* >>>>> and *attract the attention* (this is a well known principle of >>>>> design). >>>>> Using it to draw people who are trying to use the language >>>>> (period) is to >>>>> *mislead* the and make the card significantly more confusing. >>>>> >>>>> This same principle applies to outlier or deprecated features. >>>>> The *last* >>>>> thing you want is to draw people's attention to them, esp. that of >>>>> relatively naive users. >>>>> >>>>> Note that this attention drawing affect works even on >>>>> sophisticated users >>>>> (as eye tracking studies can show). So it hits *everyone*. >>>>> >>>>>>> For >>>>>>> example, if a term is deprecated, I would consider this relevant >>>>>>> knowledge >>>>>>> for my work, e.g., even if I were required to leave the old >>>>>>> term in the >>>>>>> ontology for the moment, I won't add additional occurrences, >>>>>>> and could >>>>>>> plan >>>>>>> for a future redesign. >>>>> >>>>> This is such a specialized situation as to be really quite >>>>> irrelevant for >>>>> the design of a QRG. If you want to produce such a card for >>>>> that situation, >>>>> go ahead. Even then, I would suggest *not* including it in the >>>>> "main" >>>>> working card, and producing a *separate* card for things you >>>>> should avoid. >>>>> >>>>> [snip] >>>>> >>>>>>> Such a card is good for learning by doing: One looks >>>>>>> something up once >>>>>>> or >>>>>>> twice when one stumbles over it, and afterwards one knows >>>>>>> about it and >>>>>>> its >>>>>>> special aspects, but still have the helpful card around, if >>>>>>> one forgets >>>>>>> about it again. But then it would be un-helpful if some terms >>>>>>> were not >>>>>>> mentioned in the card. >>>>>>> >>>>>> Agreed >>>>> >>>>> We should not be designing for outlier situations. You can >>>>> always cook up >>>>> a scenario where having this or that would be possible useful. >>>>> But you have >>>>> to evaluate the total costs as well. >>>>> >>>>>>> So to summarize: I would keep the terms in, and even along >>>>>>> with the >>>>>>> other >>>>>>> terms (no separate section), but with some marker ("D" = >>>>>>> "deprecated" >>>>>>> for >>>>>>> DataRange, "L" = "legacy" for most others, perhaps really "R" = >>>>>>> "RDF-Based >>>>>>> Semantics" for OntologyProperty (not clear on this)). >>>>>>> >>>>>> Seen discussion above. The proposed markers, there are also >>>>>> problems: >>>>>> for "L" - if a term is not officially deprecated, its status >>>>>> is not >>>>>> really "legacy" in a formal way; for "R" - the problem is >>>>>> ontology >>>>>> properties are treated as annotation properties in OWL 2 DL, >>>>>> that's >>>>>> they are not purely only available in RDF-based semantics. >>>>> >>>>> [snip] >>>>> >>>>> I consider this in all likelihood to damage the overall utility >>>>> and >>>>> usefuless of the card. >>>>> >>>>> Why on earth are we going here? I mean, truly, what *is* the >>>>> motivation? >>>>> This in principle can only but rarely useful and ever more >>>>> rarely useful >>>>> over time. Why go there? >>>>> >>>>> Cheers, >>>>> Bijan. >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Jie Bao >>> http://www.cs.rpi.edu/~baojie >> >> > > "Con un poco de semántica ya se consigue ir muy lejos" > > Prof James Hendler http://www.cs.rpi.edu/~hendler, @jahendler, > twitter > Tetherless World Constellation Chair > Computer Science Dept > Rensselaer Polytechnic Institute, Troy NY 12180 > > > > > >
Received on Wednesday, 27 May 2009 07:45:26 UTC