Re: A proposal for ISSUE-104 (built-in vocabulary)

On 12 Jun 2008, at 09:31, Michael Schneider wrote:
[snip]
> And now, I am not convinced anymore that it is perfectly possible  
> to have a
> reverse mapping which always properly distinguishes between syntax and
> custom usage. For example, the same list expression in an RDF graph  
> (or only
> a part of it) may be used both as part of the syntax and in a  
> custom way:
>
>     :alice rdf:type [
>         rdf:type owl:Class ;
>         owl:oneOf ( :person1 :person2 ) ]
>
>     :alice :likes ( :person1 :person2 )
>
> What to do here? The "canonical parsing process" in the current  
> reverse
> mapping cannot simply remove the list after the first axiom has  
> been mapped,
> since the list expression is still needed to process the second axiom.

They are two different lists because there are distinct BNodes after  
the oneOf and the likes (somewhat hidden by the syntactic sugar). In  
some parsing implementations, one uses bag rather than set semantics  
for the triples precisely so one can delete things immediately and  
not screw up the second. But another approach would be to delete  
triples only after they are "garbage collectable".
[snip]

> To make this clear: My original idea was to introduce custom usage  
> of RDF
> lists (and reification, and ...), *if* we can get it mainly for  
> *free*, by
> just not disallowing the respective URIs. But now, I see that the  
> cost would
> probably be much higher than I expected.

It certain seems *possible*, but, yes, there can be time bombs. I  
personally just forgot that we had disallowed property punning when  
thinking about this :(

> So I won't push this topic any further, at least not for RDF lists  
> (I did
> not yet consider RDF reification). This looks to me as something what
> /might/ be possible, but I rather tend to postpone this issue ("we  
> currently
> don't know how to do this").

Yeah. We might include text encouraging implementors to try to handle  
this in some way.

The other thing to do is to aim for a new aggregation facility that  
works well and actually gives you some modeling joy. Then, at least,  
we have a story to tell instead of "Don't do that." or "Use a custom  
shadow vocabulary that is syntactically more cumbersome and doesn't  
have extra inferential joy."

>> Under OWL Full semantics, it is really not clear what happens.
>
> The situation in OWL Full is much less complicated. :)

Unless we introduce new semantics for the OWL DL case. Obviously, if  
we just syntactically disallow it in DL, then Full is free to do  
whatever.

Cheers,
Bijan.

Received on Thursday, 12 June 2008 08:54:33 UTC