Re: Annotations that aren't safely ignored (was Re: How to specify OWL version in a document)

On 24 June 2015 at 20:49, Bijan Parsia <bijan.parsia@manchester.ac.uk> wrote:
> On Jun 24, 2015, at 13:34, "Ignazio Palmisano" <ipalmisano.mailings@gmail.com> wrote:
> [snip]
>>> Like ic:imports? :-) [1]  Or trowl:Nbox? [2]
>>>
>>> And these aren't dangerous??
>>
>> Uh, different semantics intended for some reasoners but undetectable to others.
>
> Not undetect*able*, just undetected ;)

Given the aleph-0 number of possible annotation properties with
special meanings for this or that tool, from the point of view of one
lonely tool developer the difference between the two is slim :-)
(Am I right in saying aleph-0? The set of all IRIs that can be used as
annotation properties is numerable, I think - it's just a matter of
generating all strings. Nerd sniping at its finest.)

>
> We didn't leave a good mechanism for extensions,
> so there isn't a lot of choice.
>

In hindsight yes, that would have been great. But perfection can't be
had in one iteration.
I.

>> <insert sound of a mechanic who's just been asked exactly how bad the
>> breakage is/> [3]
>>
>>
>> I'm sure I've heard of the concept somewhere else. Was that Embrace
>> and Extend? or SQL dialects?
>
> If we can activate the community group and document stuff, it could help.  Getting standarised on DL safe rules would be a good step.
> [snip]
>>> Maybe we could use annotation prop... oh, right.
>>>
>>>
>>> ?? I've no in principle objection to magic annotation properties.
>>
>> I tremble in fear.
>
> Well, in practice they are generally a bad idea ;) at least for arbitrary extensions.
>
> Magic annotation properties for onto clean (for example) seems fine (but onto clean is also largely compatible as an add on).
>
> Having a magic annotation namespace that strict tools could know to react against if unknown would help mitigate.
>
>> I.
>>
>> [1] http://www.virginiaautoservice.com/wp-content/uploads/2015/01/bigstock-Car-Repair-3295842.jpg
>>
>>> One convention that might work would be to use a faux property (e.g.
>>> kludge:isKnownMagicAnnotationProperty) for such mandatory annotation
>>> properties, and make contradictory positive and negative assertions about
>>> the property.
>>>
>>> Tools that know the right magic can discard these assertions; tools that
>>> know about the convention can signal a useful error; tools that do not know
>>> about the convention can detect an inconsistency.
>>>
>>> An alternative approach would be to use disjoint metaclasses to force
>>> inconsistency (might give better error messages / faster failure for EL).
>>>
>>> (There are also recommendations like SKOS that use annotation properties,
>>> instead of data or object properties, for properties that are central to the
>>> subject area. This is problematic for reasoners using the direct semantics.)
>>>
>>> Sorry, I don't know what you want to do. If you want to design a general
>>> extension mechanism, you can find lts of prior discussion in the owl wg wiki
>>> and archives.
>>>
>>> Cheers,
>>> Bijan.
>>

Received on Wednesday, 24 June 2015 20:09:58 UTC