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 Wednesday, 5 March 2008 19:53:38 UTC