Re: OWL Full Features in QRG

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 Friday, 22 May 2009 17:21:07 UTC