>
> We call these “relevant fields” - fields that an instance of a class is
> likely to have. To answer your question as to how these are determined, I
> believe there is some Java code that does this. Between domain
> declarations, unions of domains, OWL restrictions and various axioms that
> could be combined, there are many different modeling patterns one could use
> to define the associations between a property and a class.
> If you want to see a somewhat simplified example of such logic, you could
> take a look at spl:relevantPropertyAtClass function. Look for it in TBC
> help under TopBraid Composer
> <http://www.google.com/url?q=http%3A%2F%2F127.0.0.1%3A64360%2Fhelp%2Fnav%2F2&sa=D&sntz=1&usg=AFQjCNEmg_XBz_2yQ-vSkrd7wu9uchSLew>
> > Reference
> <http://www.google.com/url?q=http%3A%2F%2F127.0.0.1%3A64360%2Fhelp%2Fnav%2F2_14&sa=D&sntz=1&usg=AFQjCNHf8OgvglvE7-iFUp5p6tPl0yTw_w>
> > Functions
> Overview.
This is what i'm looking for.
Thanks a lot
Gabriele Morlini
On Wednesday, February 10, 2016 at 5:51:47 PM UTC+1, Irene Polikoff wrote:
>
> Hi Gabriele,
>
> What you are seeing in the UI is unrelated to inferencing. It is about
> creating helpful editing user interfaces.
>
> If a model says that {foaf:firstName rdfs:domain foaf:Person} and then you
> create a subclass of foaf:Person such as for example:Student, there is no
> RDFS inferencing that would conclude that if you are a student you would
> have a first name or that if you have a first name, you are a student.
>
> The inferencing would only infer that if you have a first name you are a
> person and, subsequently, an Agent as Person is a subclass of
> foaf:Agent.This is fine from the knowledge discovery/classification
> perspective. However, from the editing perspective, users creating new
> students want to see the first name as one of the fields for them to enter
> information in.
>
> We call these “relevant fields” - fields that an instance of a class is
> likely to have. To answer your question as to how these are determined, I
> believe there is some Java code that does this. Between domain
> declarations, unions of domains, OWL restrictions and various axioms that
> could be combined, there are many different modeling patterns one could use
> to define the associations between a property and a class.
>
> If you want to see a somewhat simplified example of such logic, you could
> take a look at spl:relevantPropertyAtClass function. Look for it in TBC
> help under TopBraid Composer <http://127.0.0.1:64360/help/nav/2> >
> Reference <http://127.0.0.1:64360/help/nav/2_14> > Functions Overview.
>
> If you, however, use SPIN to run standard RDFS or OWL-RL inferences, there
> wouldn’t be anything inferred that connects foaf:firstName and
> example:Student.
>
> Regards,
>
> Irene Polikoff
>
>
> From: Gabriele Morlini <[email protected] <javascript:>>
> Reply-To: <[email protected] <javascript:>>
> Date: Wednesday, February 10, 2016 at 10:31 AM
> To: TopBraid Suite Users <[email protected] <javascript:>>
> Subject: Re: [topbraid-users] How does TopBraid Inference of Domain of
> Subclass
>
> Thanks for the timely answer, but my question is why the fact "property p
> is just as 'possible' for I1 as for I0" have been showed, in the Domain
> tab, before any reasoner is started from GUI.
> I'm expecting that the "possibility" could be translate in an axioms that
> could by added in the ontology, as any other inference, but this could not
> be done.
>
> I'm asking Consequently how TopBraid was able to done this
> "inference"(Reasoner? Spin? Other?), and why this inference is not showed
> as any other inference.
> My dupt is that inference is not compliant with other inference or simply
> in TopBraid lack of the possibility of add this axioms to ontology.
>
> My scope is use TobBraid as "reasoner" and generator of more complete
> ontology as base for futher investigation.
>
> On Wednesday, February 10, 2016 at 10:59:23 AM UTC+1, David Price wrote:
>>
>> Hi,
>>
>> You’ve stated this :
>>
>> A rdf:type owl:Class
>> B rdf:type owl:Class
>> B rdfs:subClassOf A
>> p rdf:type owl:DatatypeProperty
>> p rdfs:domain A
>>
>> and now let’s add individuals:
>>
>> I0 rdf:type A
>> I1 rdf:type B
>>
>> an OWL reasoner will infer
>>
>> I1 rdf:type A
>>
>> so if you look at the inferences, I1 is an member of A just like I0 is a
>> member of A and therefore the property p is just as “possible” for I1 as
>> for I0. You do not need the concept of “inheritance” in this picture at
>> all, it’s “subset" that is in play (B being a subset of A … i.e. ALL
>> members of B are members of A). Anything you say wrt members of A and their
>> properties/restrictions is applicable to members of B in the same way
>> because members of B ARE members of A via inference.
>>
>> Cheers,
>> David
>>
>> UK +44 7788 561308
>> US +1 336 283 0606
>>
>>
>>
>>
>> On 10 Feb 2016, at 09:17, Gabriele Morlini <[email protected]> wrote:
>>
>> Hi,
>>
>> When I define a property "P" with a domain Class "A", TopBraid
>> automatically add property as "inferred" in the domain of all class and
>> subclass of "A".
>>
>> I have already read the previous post:
>> https://groups.google.com/forum/#!topic/topbraid-users/90SizV7nmWM
>> https://groups.google.com/forum/#!topic/topbraid-users/90SizV7nmWM
>> where they debeate of the correctness and semantics of the
>> inference/Inheritance in OWL/RDFS.
>>
>> My question is How it's done by TobBraid?
>> With a SPIN rule? with a reasoner? other?
>>
>> Thanks in advance
>> Gabriele
>>
>> --
>> 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]
> <javascript:>
> ---
> 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), 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.
