- From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
- Date: Thu, 21 May 2009 21:48:49 +0100
- To: Jie Bao <baojie@gmail.com>
- Cc: Michael Schneider <schneid@fzi.de>, "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
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 Thursday, 21 May 2009 20:49:27 UTC