<and can indeed reasoners do 3) because they can already do 2, which is in
fact 1and3)?>

You should experiment and see what happens. 3 alone should give you an
inference :B rdf:type :Class1 in my example.

Irene


From:  "Bohms, H.M. (Michel)" <[email protected]>
Reply-To:  <[email protected]>
Date:  Wednesday, April 15, 2015 at 3:19 AM
To:  "[email protected]" <[email protected]>
Cc:  "[email protected]" <[email protected]>
Subject:  FW: FW: [topbraid-users] sufficient modelling

 

Hi Irene,

 

Thx for your information/explanation. Since you say " If, for some unusual
reason, you wanted to create restrictions independently from the named
classes they are used to define, y"

I try to reformulate a bit better, just to better understand (in my
reasoning it's not an unuasual reason so I probably don't understand it
right....).

 

Suppose I have A(x) and R(x), A being a named class and R being an anonymous
restriction class. I then see three options that could be relevant:

1) A(x) -> R(x)

You define the class A and define the restriction R for it and make A a
subclass of R. R is a necc. condition for A.

2) A(x) <-> R(x)

You define a class A and define again restriction R but now say equivalent
class iso subclass.

R is a necc. and also sufficient condition for A (in case you know something
satisfies R(x) you know it is a member of A(x) so you could automatically
classify.

 

So these two ways are the typical constructs I up to now encountered and
used. But now the unusual one, in second sight doesnt seem so unusual at all
(well to me):

3) R(x) -> A(x)

Now we cannot start with a defined class but have to first instantite R(x)
after making it visible in the class tree.

So we define a restriction class and then say its a subclass of A(x).

Now we can only partially/incomplete classify because R(x) is optional for
A.

 

(so in my view 2) is just 1) AND 3)....)

 

Is this storysofar still ok?

and can indeed reasoners do 3) because they can already do 2, which is in
fact 1and3)?

 

Thx again! Michel

 

 

 

2015-04-14 17:41 GMT+02:00 Bohms, H.M. (Michel) <[email protected]>:

 
 
 Dr. ir. H.M. (Michel) Bohms
Sr. Research Scientist
Structural ReliabilityT +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E [email protected] <mailto:[email protected]> Location
<http://www.tno.nl/locaties/DTM>

 
 <http://www.tno.nl/>
This message may contain information that is not intended for you. If you
are not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. TNO accepts no
liability for the content of this e-mail, for the manner in which you use it
and for damage of any kind resulting from the risks inherent to the
electronic transmission of messages.
 

From:[email protected]
[mailto:[email protected]] On Behalf Of Irene Polikoff
Sent: dinsdag 14 april 2015 16:16
To: [email protected]
Subject: Re: [topbraid-users] sufficient modelling
 

Michel,

 

If I understood you correctly, the answer is ³it doesn¹t matter, the end
result is always the same².

 

Create a restriction your usual way, then expand it in the class form and
ctrl click on the owl:Restriction in the expanded display to navigate to it.
You will see that it has an instance (or several instances depending on how
many restrictions you have created). These instances are anonymous resources
of type owl:Restriction. You can explore them.

 

If, for some unusual reason, you wanted to create restrictions independently
from the named classes they are used to define, you could go to Preferences
in TBC and adjust them for the Classes tree so that owl:Restriction appears
there. Then create instances. Put the appropriate properties in the
owl:onProperty widget and appropriate classes or values into owl:hasValue,
owl:someValuesFrom or whatever you want to use. Then, go to a named class
and drag and drop the appropriate instance into the rdfs:subClassOf or
owl:equivalentClass widgets.

 

If you look at the resulting RDF, it will be identical irrespective of how
you got there (provided that it is the same type of restriction).

 

<Hwat does it mean to be sufficient but NOT necessary? (potential incomplete
classification?)>

 

"Sufficient and necessary" terminology is not part of OWL. It is Protégé
specific terminology. In OWL, there are rdfs:subClassOf and
owl:equivalentClass connections to some other classes. The meaning ((what
could be inferred) based on such relationships to restrictions is defined in
the OWL spec. It depends on the type of restriction. For example:

 

If :Class1 is a subclass of a restriction [onproperty hasID,
owl:hasValue=14220), then for each :A rdf:type :Class1, you can infer that
:A :hasId Œ14220¹. 

But if you have a resource :B of some other or unknown type and :B :hasId
Œ14220¹, you can¹t infer that :B rdf:type :Class1.

 

If :Class1 is an equivalent class of this restriction, then you can make
both inferences - :A :hasId Œ14220¹ and B rdf:type :Class1.

 

Regards,

 
Irene Polikoff

 

 

From: "Bohms, H.M. (Michel)" <[email protected]>
Reply-To: <[email protected]>
Date: Tuesday, April 14, 2015 at 5:53 AM
To: "[email protected]" <[email protected]>
Subject: [topbraid-users] sufficient modelling

 

I have a question about modelling ³subclassses the other way round².
 
Typically I model, classes with restrictions being described as subclasses
of anonom. classes.
Sometimes I do the same with equivelnt classes in case of necc. & sufficient
conditions.
 
But, til now, I never modelled only the way backŠ.saying a an. Restriction
class as subclass of a named class.
(so my LHS of x-> y is now something like [onproperty hasID,
owl:hasValue=14220)
 
With that info I could check an instance for this code and derive it is an
instance of my named class.
 
Another example: everything having a xHeight is actially an X. (same but now
using someValuesFrom iso hasValue)
 
So now my questions:
-       How do I do this in topbraid (till now it was the other way round,
defining a class and then a restriction)

-       Since equivalence is both ways I guess the way back only also makes
sense right?

-       Hwat does it mean to be sufficient but NOT necessary? (potential
incomplete classification?)

-       How do reasoners deal with this backward Subclassing (do they do it?
Is it much harder for them for such complex LHSŠ?)

-        

Thanks a lot! Michel
 
 
 
 Dr. ir. H.M. (Michel) Bohms
Sr. Research Scientist
Structural ReliabilityT +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E [email protected] <mailto:[email protected]> Location
<http://www.tno.nl/locaties/DTM>

 
 <http://www.tno.nl/>
This message may contain information that is not intended for you. If you
are not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. TNO accepts no
liability for the content of this e-mail, for the manner in which you use it
and for damage of any kind resulting from the risks inherent to the
electronic transmission of messages.
 
-- 
You received this message because you are subscribed to the Google Group
"TopBraid Suite Users", the topics of which include Enterprise Vocabulary
Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid
Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
--- 
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), Reference Data Manager (RDM), TopBraid Composer, TopBraid
Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
<mailto:[email protected]>
--- 
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), Reference Data Manager (RDM), TopBraid Composer, TopBraid
Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
--- 
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), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, 
TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
--- 
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