Re: comments on RDF mapping

My understanding is that there is a requirement to be able to create  
properties attached to classes that have more inference support than  
is currently possible using annotation properties. For example, it is  
desirable that an "annotation property" for an editing time stamp  
should have a range that is xsd:date, or, for SKOS, we would like  to  
be create subproperties of rdfs:label.

Alan Rector articulated these cases initially, IIRC. I suspect they  
are recorded somewhere amongst  the OWLED stuff.

I believe that you have correctly identified the missing entailments.  
Those entailments, while desirable in general, are not necessary for  
the above use case. As I understand it, the reason those entailments  
are not supported is that there is not enough theoretical work to  
ensure that they can be implemented in a sound, complete, and  
decidable manner.

Proponents of punning would label this:

"OWL DL, now with more, but not all, of OWL Full goodness"

I would suggest that instead of disallowing this use case, we instead  
focus on adding whatever structural restrictions we can to reinforce  
the desired future case - that the URI identifies a single thing. Off  
the top of my head, for instance, we might add that no property in a  
property chain be declared/used as a datatype property.

-Alan


On Oct 29, 2007, at 2:00 PM, Jeremy Carroll wrote:

> I think the best way to address punning is by stating the  
> requirement and looking at whether:
>
> a) this requirement is a requirement, and how widespread
> b) whether punning meets this requirement
>
> The only articualtion of the requirement that I am familiar with is:
>
> http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.19-Classes- 
> as-instances
>
>
> During the earlier group I felt that it was understood that the  
> requirement was not just that you could use the same name for a  
> class as for an instance, but that some logical consequences would  
> follow.
>
> for example
> http://www.w3.org/TR/owl-test/byFunction#sameAs-001
>
> This is an OWL 1.0 Full entailment, which (perhaps with minor  
> syntactic change) would become an OWL 1.1 DL non-entailment (if I  
> have understood punning semantics correctly).
>
> This seems like a divergence away from OWL 1.0 balance between Full  
> and DL, and also a divergence away from what I believe the  
> requirement of classes as instances is. If two items are the same  
> instance, then they are necessarily the same class.
>
> The tests that I think express the punning issue are:
>
>
> <a> owl:sameAs <b>
>
> entails
>
> <a> owl:equivalentClass <b>
>
>
> and
>
>
> <a> owl:sameAs <b>
>
> entails
>
> <a> owl:equivalentProperty <b>
>
>
> I currently believe that the member submission OWL 1.1 semantics  
> has these both as non-entailments, and that a requirements doc for  
> the use case of using an instance URI as a class URI or an instance  
> URI as a property URI would have these entailments as holding.
>
> (Obviously it is possible to give a post hoc rationale in which  
> these entailments are unimportant - it is easier to tell whether or  
> not a design meets a requirement if the requirement is written  
> down, before the design is)
>
> Since the OWL 1.0 design solves this problem, in the manner given by
>
> http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.19-Classes- 
> as-instances
> [[
> Part of OWL Full.
> ]]
> (and syntactically excluded from OWL DL)
>
> I personally see a variation in which this becomes
>
> "Part of OWL Full; syntactically permitted in OWL DL, but with  
> weaker semantics."
>
> as a backward step
>
> Jeremy
>
>
>
>
>
> Alan Ruttenberg wrote:
>> Hi Jeremy,
>> My understanding is that the intention is not to provide a way to  
>> get around the univocity of a URI. Rather, some aspects of making  
>> that work are not currently known to be decidable, so a compromise  
>> is offered  insofar as some entailments that would be  
>> theoretically desired are skipped, in order to make progress  
>> towards a shared goal.
>> I wonder whether we can make some fixes to address cases such as  
>> the one you point out, particularly when there is no impact on  
>> decidability. So perhaps we could consider, in this case,  
>> abandoning the distinction between subObjectPropertyOf and  
>> subDataPropertyOf so that a subProperty assertion applies to both  
>> kinds.
>> There will still be an issue with property chains. But I wonder  
>> what you think about the general strategy: Making it clear in the  
>> documentation that we discourage use of punning to get around  
>> univocity, that current behavior that allows this may disappear in  
>> future versions of OWL, and patching, to the extent that is  
>> feasible without new theoretical work, the current spec in the way  
>> that I suggest above.
>> As a meta point, could we stay away from statements of the sort :  
>> "i.e. punning is an unhelpful idea."? I don't think it is helpful,  
>> as there are clearly situations where other people do think it is  
>> helpful. Let's instead focus on making things work as best we can.
>> -Alan

Received on Tuesday, 30 October 2007 14:07:09 UTC