adding rule names. Re: A proposal for a way forward regarding fragments

Boris,

Thanks for adding the new rules. And I don't mind keeping those rules in 
Table 3.

I added a "Rule name" column to Table 1. If this looks ok to you, I will 
do the same thing for other tables as well.

Thanks,

Zhe

Boris Motik wrote:
> Hi,
>
> OK, I see what you say about the union. In fact, a similar thing holds for the intersection.
>
> I've added two new rules to Table 5. I would still keep the rules in Table 3: these are redundant; however, they naturally follow
> from the idea that the definition of OWL-R is obtained by weakening the semantic conditions of OWL Full. An implementation can,
> however, safely ignore these rules.
>
> Regards,
>
> 	Boris
>
>
>   
>> -----Original Message-----
>> From: Alan Wu [mailto:alan.wu@oracle.com]
>> Sent: 05 March 2008 19:45
>> To: Boris Motik
>> Cc: bcg@cs.man.ac.uk; hendler@cs.rpi.edu; 'Jeremy Carroll'; 'Michael Schneider'; OWL Working Group WG
>> Subject: Re: A proposal for a way forward regarding fragments
>>
>> Boris,
>>
>> Copying WG on this.
>>     
>>> I've extended the rules table as you've suggested and have added a new table with constraints for
>>>       
>> the schema entailments. Let me
>>     
>>> know what you think. Below are the responses to other questions.
>>>
>>>       
>> That is quick, Boris! Thank you. I will review the changes.
>>     
>>>>> * If rdfs:subClassOf triples can be generated, then those N rules in
>>>>> Table 3 regarding rdf:unionOf (should be owl:unionOf)
>>>>>    can be simplified into one rule deducing that T(?C1,
>>>>> rdfs:subClassOf,  ?C), T(?C2,  rdfs:subClassOf,  ?C) ...
>>>>>    T(?Cn,  rdfs:subClassOf,  ?C)
>>>>>
>>>>>           
>>>> I'm sorry, I don't really understand this comment.
>>>>
>>>>         
>>>       
>>>> The idea is instead of N separate rules, we can have just one rule (please forgive me for
>>>> introducing a new syntax).
>>>> C owl:unionOf {c1, c2, ... cn}
>>>> ===>  c1 rdfs:subClassOf C,   c2 rdfs:subClassOf C,  .... cn rdfs:subClassOf C.
>>>>
>>>>         
>>> I am not sure whether this would solve our problem. The reason why we need n rules is because the
>>>       
>> disjunction (and the same holds
>>     
>>> for conjunction as well) in OWL can have an arbitrary number of disjuncts (i.e., conjuncts). This
>>>       
>> is why we introduced n rules: we
>>     
>>> don't know in advance what the arity is going to be.
>>>
>>> Now I understand that this is quite impractical for implementations. There might be a way of
>>>       
>> dealing with this; I have to think
>>     
>>> about it more though. In the worst case, implementors can simply instantiate these rules for all
>>>       
>> "reasonable" numbers of n.
>>     
>> I guess I did not make myself clear on this. If we change the rule from
>> its original form (N rules that are operating on instances) to one rule
>> that generates N rdfs:subClassOf  schema  triples,  then implementation
>> is easy, right?
>>
>> The generation of those N schema triples is just a one time deal. The
>> rest of the work will be handled by the first rule in Table 4.
>>     
>>>>> I don't think we need this restriction on the rules: we won't generate an invalid triple as long
>>>>> as p is not a blank node or a literal. Thus, as long as the input obeys is syntactically correct,
>>>>> it seems to me that none of the rules should really worry about producing syntactically correct
>>>>> triples.
>>>>>
>>>>>           
>>>       
>>>> Let me use an example. It seems to me that the following is allowed syntactically in OWL-R FULL
>>>> (RDFS 3.0).
>>>>
>>>> T(http://abc/d#1,  owl:sameAs,  "Hello")
>>>>
>>>> If we apply symmetricity, then we get an illegal triple, right?
>>>>
>>>>         
>>> Yes, true. However, the problem is not in the rules; rather, the problem is in the first triple:
>>>
>>> T(http://abc/d#1,  owl:sameAs,  "Hello")
>>>
>>> This triple equates resources to literals. In OWL DL this is illegal. I am not sure I understand
>>>       
>> exactly what the meaning of this in
>>     
>>> light of OWL Full is; perhaps Jeremy can shed light on this. I do believe, though, that we should
>>>       
>> either (1) declare the knowledge
>>     
>>> base to the in error or (2) indeed replace 1 with "Hello" in all triples. Simply ignoring the
>>>       
>> semantics of equality for this triple
>>     
>>> would probably be not such a good idea.
>>>
>>>       
>> I am not so sure on this one myself. (1) sounds better.
>>     
>>> Regards,
>>>
>>> 	Boris
>>>
>>>       
>> Thanks,
>>
>> Zhe
>>     
>
>
>

Received on Thursday, 6 March 2008 15:59:04 UTC