Re: OWL Full Features in QRG

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

Received on Monday, 25 May 2009 10:11:48 UTC