W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2009

Re: OWL Full Features in QRG

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Fri, 22 May 2009 10:13:41 +0100
Message-Id: <F44448F1-A637-4278-B977-6F9F8D3CF096@comlab.ox.ac.uk>
Cc: Jie Bao <baojie@gmail.com>, Michael Schneider <schneid@fzi.de>, "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
To: Bijan Parsia <bparsia@cs.manchester.ac.uk>
I must say that I am in full agreement with Bijan here -- adding  
distinguishing marks would be going backwards.

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.

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.

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.
>
Received on Friday, 22 May 2009 09:14:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:12 UTC