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

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 ;)

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

> <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 19:49:36 UTC