Re: OWL Full Features in QRG

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 Tuesday, 26 May 2009 23:52:08 UTC