Hi Holger,

I understand your confusion, and indeed this thread is taking all kind of 
directions.
To be clear: I can create what I need (which is shown in attachment 
classC). But what is left is a wish for a more detailed explanation of the 
behaviour of TBC, in particular complete mode filtering in Inference 
configuration. This I would like to have for QA purposes. We are building a 
complex taxonomy that will be aligned with external ontologies. I need to 
be able to verify the consistency of al this, and explain/show to people 
with a OO background how RDFS/OWL reasoning works. 

I also expressed some frustration about the working of the complete mode 
switch. My point here is that it is often necessary to enable complete mode 
to be able to see the working of inference according to the spec. While in 
the documentation this is characterized as "redundant". *It seems that the 
filtering of one triple* (in this case X rdfs:subClassOf X ) *causes the 
filtering of other - not redundant, but desired - statements*, even to the 
point of not detecting inconsistency...(I referenced above to another 
thread)  This is confusing to TBC users, myself I have spent innumerable 
hours figuring out whether I understand the tool and the OWL spec.
I asked if you could share the filtering expressions with us, got a 
negative response, which I can understand because probably this involves a 
lot more. 

I don't need to keep you any more busy. As far as I am concerned the thread 
can be closed with a few comments from you regarding my following 
assumption: when I run the SPIN OWL2-RL reasoner on the ontology listed in 
the initial thread entry above with complete mode OFF, I see no results for 
the scm-sco rule because statements are filtered out that cause the 
hierarchy tree to be messed up, in particular X rdfs:subClassOf X . Because 
of this, other statements like :C rdfs:subClassOf :A are also not displayed.

Thanks, Lieke

On Thursday, 21 August 2014 03:49:37 UTC+2, Holger Knublauch wrote:
>
>  Hi Lieke,
>
> I admit I am a bit confused by what the remaining open issue is (it has 
> become a complex thread). Could you send a Turtle file for your scenario, 
> with a list of triples that you would like to see but cannot?
>
> Thanks
> Holger
>
>
> On 8/20/2014 19:17, Lieke Verhelst wrote:
>  
> Hi Scott, thanks, I can live with that, but unfortunately my question is 
> not fully answered.
>
> Sorry for acting persistent but I really need to understand what is 
> happening. We are in the process of QA-ing our work and we use TBC to 
> create the ontology and it we would also like to use it to check the 
> quality of what we make. For this I need to understand nuts and bolts.
>
> Some more background: 
> I am investigating how to show subclass transitivity along all levels by 
> inference . This is a tricky thing, because quote "The "owl.owl" file is 
> only an RDFS schema, so the transitivity of rdfs:subClassOf is not stated" 
> (quote from: 
> http://answers.semanticweb.com/questions/9997/rdfssubclassof-not-asserted-to-be-of-type-transitiveproperty-why)
>  
>
> For this reason many tools don't infer all the levels of the superclasses. 
> A solution to make this work that is often suggested is to add the triple 
> rdfs:subClassOf rdf:type owl:TransitiveProperty .
>
> This post in answers.semanticweb.com is from 2011 and it explains that 
> SPIN uses the scm-sco rule with the SPARQL "*" construct to generate the 
> transitive triples. (BTW In my version of TBC (I tested in 4.3) this rule 
> is now different, without the "*" but with 3 levels instead of 2. )
>
> What I would like to achieve is seeing in a form all the inferred levels 
> of superclasses. Just like I see this in classC (attachment) so my mission 
> is completed, but I need to understand how this works. When I look at the 
> explanation of the mechanism behind this it does not make sense.
>
> What is happening is: with Complete mode on I see all the inferred 
> superclasses above C. Without complete mode I see no inferred triples. From 
> your answer I must conclude: complete mode filters out the :C 
> rdfs:subClassOf :C (it does). But it filters out a lot more that is not 
> documented, namely every triple that you see in the attached image. 
> My assumption is that because of one filter pattern all the rest is 
> filtered out too (is that not unwanted???). And the owl:equivalentClass 
> (not mentioned in the list of filtered constructions in the Help) is 
> generated  automatically from :a rdfs:subClassOf :b and :b 
> rdfs:subClassOf :a
>
> My problem is: the complete mode off filters out too much. I also refer to 
> your answer to the question by Charles Mead on July 25 about detecting 
> inconsistencies:
>
> https://groups.google.com/forum/#!searchin/topbraid-users/inconsistent$20complete$20mode/topbraid-users/ucosD2QfC7Y/VV2DufvyvPIJ
> Basically the conclusion is that  you need to turn complete mode on to be 
> able to see inconsistencies. That is silly.. How does any average user 
> know? BTW the proposed solution dos not work for me (at class level).
>
> Also one would expect that adding the triple rdfs:subClassOf rdf:type 
> owl:TransitiveProperty . to the file would infer all the superclasses 
> without complete mode on. It does not (it does with complete mode on). 
> Shouldn't prp-trp take care of this? I suppose the results are also 
> filtered out because of rdfs:subClassOf in a filter rule, since any other 
> owl:TransitiveProperty works fine.
>
> One concluding remark: I really appreciate that your product shows the 
> rules that are used for reasoning, plus the fact that you can write your 
> own. The complete mode spoils that unfortunately. 
>
>
>
>
>
> On Tuesday, 19 August 2014 21:45:13 UTC+2, Scott Henninger wrote: 
>>
>>  Lieke; I think the help file you found defines just what the filters 
>> are.  Some is there to preserve useful features of a hierarchy of classes.
>>
>> In terms of the "...immediate superclasses which are also transitively 
>> related...", without this filter, two things will happen: the tree will be 
>> completely flat, and each class is a subclass of itself.  The latter of 
>> which evokes a kind of infinite loop, as a class will always have a 
>> subclass, which is itself.  Basically TopBraid is filtering these 
>> entailments so the tool remains usable, but standard inference profiles can 
>> still be used.
>>
>> -- Scott
>>
>> On 8/19/2014, 1:14 AM, Lieke Verhelst wrote:
>>  
>> Thanks Scott and Irene, 
>>
>> I found the rule that was applied and it was what I expected to see.
>> In the Help it is documented which statements are filtered when Complete 
>> Mode is not turned on:
>>
>> "*Complete Mode: Do not filter redundant inferences* - when this 
>> checkbox is not selected, the following redundant statements will be 
>> removed from the set of inferences. By default, it is not selected. 
>>    
>>    - rdf:type statements if the instance also has a subclass of the type 
>>    as one of its rdf:types. 
>>    - rdfs:subClassOf statements of inconsistent classes (except with 
>>    owl:Nothing). 
>>    - rdfs:subClassOf statements of anonymous classes. 
>>    - rdfs:subClassOf statements with anonymous classes (without 
>>    restrictions). 
>>    - rdfs:subClassOf statements with immediate superclasses which are 
>>    also transitively related via rdfs:subClassOf. 
>>    - rdfs:subClassOf statements with owl:Thing if another superclass 
>>    exists. 
>>    - owl:disjointWith statements with inconsistent classes. 
>>    - owl:disjointWith statements between subclasses and superclasses. 
>>    - owl:equivalentProperty statements between subproperties." 
>>
>>
>> ,.. but this could lead to confusion. In my case I did not understand the 
>> word "immediate" in the sentence, :
>> rdfs:subClassOf statements with immediate superclasses which are also 
>> transitively related via rdfs:subClassOf
>> (I think it does not belong here because all superclasses above are 
>> displayed, not only the immediate)
>>
>> Can you share with us what exactly are the filter expressions that are 
>> involved in the Complete Mode settings? 
>>
>> Thanks, Lieke
>>
>>
>> On Monday, 18 August 2014 13:03:29 UTC+2, Lieke Verhelst wrote: 
>>>
>>> Dear all,
>>>
>>> I have a simple ontology with only classes and subclasses:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * # baseURI: http://example.com/subclass <http://example.com/subclass> 
>>> @prefix :        <http://example.com/subclass# 
>>> <http://example.com/subclass#>> . @prefix owl:     
>>> <http://www.w3.org/2002/07/owl# <http://www.w3.org/2002/07/owl#>> . @prefix 
>>> rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns# 
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> . @prefix rdfs:    
>>> <http://www.w3.org/2000/01/rdf-schema# 
>>> <http://www.w3.org/2000/01/rdf-schema#>> . @prefix xsd:     
>>> <http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#>> . 
>>> <http://example.com/subclass <http://example.com/subclass>>       rdf:type 
>>> owl:Ontology ;       owl:versionInfo "Created with TopBraid 
>>> Composer"^^xsd:string . :A    rdf:type owl:Class ;       rdfs:label "A "@en 
>>> ;       rdfs:subClassOf owl:Thing . :B    rdf:type owl:Class ;       
>>> rdfs:label "B "@en ;       rdfs:subClassOf :A . :C    rdf:type owl:Class ; 
>>>       rdfs:label "C "@en ;       rdfs:subClassOf :B .*
>>>
>>>
>>> When I enable Complete Mode inferencing (see attachment inference 
>>> settings.png) and run inferences I see something that looks like 
>>> rdfs:subClassOf transitive behaviour (see attachment classC.png). Similar 
>>> to:
>>>
>>> CONSTRUCT {  ?subject rdfs:subClassOf ?object }
>>> WHERE {     ?subject rdfs:subClassOf+ ?object .}
>>>
>>> exept that the triple :C rdfs:subClassOf rdfs:Resource is not generated 
>>> when inferencing like this.
>>>
>>> What is it exactly that I see?
>>>
>>> thanks, Lieke
>>>
>>>
>>>   -- 
>> -- You received this message because you are subscribed to the Google
>> Group "TopBraid Suite Users", the topics of which include Enterprise 
>> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid 
>> Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
>> To post to this group, send email to
>> [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/topbraid-users?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "TopBraid Suite Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>   -- 
> -- You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include Enterprise 
> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid 
> Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
> To post to this group, send email to
> [email protected] <javascript:>
> To unsubscribe from this group, send email to
> [email protected] <javascript:>
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
>  

-- 
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary 
Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, 
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to