Split or not?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Split or not?

Julian Vincent-2
It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?

Julian Vincent
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: Split or not?

Csongor Nyulas
Administrator
Hi Julian,
I am not sure what you mean by "amalgating subclass axioms". Can you
give us an example?

Csongor

On 03/03/2014 02:47 PM, Julian Vincent wrote:
> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
>
> Julian Vincent
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

amalgamating subclass axioms - why?

Julian Vincent-3
It's all there in Protege, as items 7 and 8 under the menu item 'Refactor'.  

To illustrate, set up a class and allow it to have 3 very similar subclass axioms - let's say you enter "hasPart some A", "hasPart some B" and "hasPart some C".  These are 3 separate axioms.  Now go to the menu item 'Refactor' and check on 'Amalgamate subclass axioms' and you'll find that the 3 separate axioms you have just entered have been amalgamated into a single (verbose) axiom, strung together with the word "and".  Play a little more . . . highlight this newly amalgamated axiom and generate the closure axiom which will generate the axiom "hasPart only (A or B or C)".  This can't be reduced to separate axioms by checking 'split subclass axioms', but your original 3 axioms will be reformed separated and you can then rewrite them in the same form as the closure axiom - i.e. "hasPart some (A and B and C)" (I will call this the 'concatenated' form.  There may be a proper name for it.  I don't know)  You can then amalgamate both statements as before.  All these forms will be accepted
  by the Reasoner (I use FaCT++).
So I repeat my question - what, if any, is the advantage of amalgamation?  Why is it made available (but, like several items in the menu) not mentioned in the tutorial?  What is the difference between the verbose and concatenated forms of the amalgamated axioms?

This was brought up by my discovery that a search technique I was using with DL Query seems not to be available any more (or is it some quirk of the new Mac OS X 9.2?).  Given the three separate "hasPart . . . " axioms I used to be able to search for a class which contained any two of the axioms by entering (the concatenated form) "hasPart some (A and B)" (or A and C   or  B and C) in the DL Query box, highlight the Execute box just beneath, and get the name(s) of the class(es) containing that combination of axioms, amongst others.  However, now I can't do it. I can enter "hasPart some A and hasPart some B" and get the class(es) returned.  But I can't enter the concatenated form of the axiom into DL Query and expect a useful result if that format is not available in the classes I am querying.  What happened?  As far as I can see there is no logical difference between the separated axioms or the amalgamated axioms, whether in verbose or concatenated form.  

If all this seems a bit confusing I suggest you go through this sequence carefully and slowly and experience the inconsistencies.  Do they constitute a bug or do they express a remarkably subtle feature that I am incapable of recognising.  This is quite serious as far as I am concerned, since it would require my changing something like 2 000 groups of axioms if the concatenated query is no longer functional.

Julian Vincent



On 4 Mar 2014, at 00:27, Csongor Nyulas <[hidden email]> wrote:

> Hi Julian,
> I am not sure what you mean by "amalgating subclass axioms". Can you give us an example?
>
> Csongor
>
> On 03/03/2014 02:47 PM, Julian Vincent wrote:
>> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
>>
>> Julian Vincent
>> _______________________________________________
>> protege-user mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: amalgamating subclass axioms - why?

samsontu
Hi Vincent,

Thanks for bringing to my attention these Protege 4 features I haven't used before. I think these splitting and amalgamation are purely syntactic changes. Aside from taste and convenience, I don’t know of any reason to prefer one form or another.

However, I don’t understand your “concatenated form” (hasPart some (A and B)). It is not equivalent to ((hasPart some A ) and (hasPart some B)). So using it as the query expression will yield different than what you get if you use ((hasPart some A ) and (hasPart some B)) as the query expression.

If you can be more specific about the query you were able to make before and the results it returned, and the query you have to make now (and the results it returns), it would help me to understand the issue. (A sample ontology would be helpful.)

Thank you.

With best regards,
Samson


On Mar 6, 2014, at 5:13 AM, Julian Vincent <[hidden email]> wrote:

> It's all there in Protege, as items 7 and 8 under the menu item 'Refactor'.  
>
> To illustrate, set up a class and allow it to have 3 very similar subclass axioms - let's say you enter "hasPart some A", "hasPart some B" and "hasPart some C".  These are 3 separate axioms.  Now go to the menu item 'Refactor' and check on 'Amalgamate subclass axioms' and you'll find that the 3 separate axioms you have just entered have been amalgamated into a single (verbose) axiom, strung together with the word "and".  Play a little more . . . highlight this newly amalgamated axiom and generate the closure axiom which will generate the axiom "hasPart only (A or B or C)".  This can't be reduced to separate axioms by checking 'split subclass axioms', but your original 3 axioms will be reformed separated and you can then rewrite them in the same form as the closure axiom - i.e. "hasPart some (A and B and C)" (I will call this the 'concatenated' form.  There may be a proper name for it.  I don't know)  You can then amalgamate both statements as before.  All these forms will be accepted
>  by the Reasoner (I use FaCT++).
> So I repeat my question - what, if any, is the advantage of amalgamation?  Why is it made available (but, like several items in the menu) not mentioned in the tutorial?  What is the difference between the verbose and concatenated forms of the amalgamated axioms?
>
> This was brought up by my discovery that a search technique I was using with DL Query seems not to be available any more (or is it some quirk of the new Mac OS X 9.2?).  Given the three separate "hasPart . . . " axioms I used to be able to search for a class which contained any two of the axioms by entering (the concatenated form) "hasPart some (A and B)" (or A and C   or  B and C) in the DL Query box, highlight the Execute box just beneath, and get the name(s) of the class(es) containing that combination of axioms, amongst others.  However, now I can't do it. I can enter "hasPart some A and hasPart some B" and get the class(es) returned.  But I can't enter the concatenated form of the axiom into DL Query and expect a useful result if that format is not available in the classes I am querying.  What happened?  As far as I can see there is no logical difference between the separated axioms or the amalgamated axioms, whether in verbose or concatenated form.  
>
> If all this seems a bit confusing I suggest you go through this sequence carefully and slowly and experience the inconsistencies.  Do they constitute a bug or do they express a remarkably subtle feature that I am incapable of recognising.  This is quite serious as far as I am concerned, since it would require my changing something like 2 000 groups of axioms if the concatenated query is no longer functional.
>
> Julian Vincent
>
>
>
> On 4 Mar 2014, at 00:27, Csongor Nyulas <[hidden email]> wrote:
>
>> Hi Julian,
>> I am not sure what you mean by "amalgating subclass axioms". Can you give us an example?
>>
>> Csongor
>>
>> On 03/03/2014 02:47 PM, Julian Vincent wrote:
>>> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
>>>
>>> Julian Vincent
>>> _______________________________________________
>>> protege-user mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>
>> _______________________________________________
>> protege-user mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: amalgamating subclass axioms - why?

Eric Prud'hommeaux
* Samson Tu <[hidden email]> [2014-03-06 16:48-0800]
> Hi Vincent,
>
> Thanks for bringing to my attention these Protege 4 features I haven't used before. I think these splitting and amalgamation are purely syntactic changes. Aside from taste and convenience, I don’t know of any reason to prefer one form or another.

Presuming (and I haven't done the exercise Vincent outlined in his last mail) that the RDF representation of the split form is:

  my:Derived rdfs:subClassOf
          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] .

and the amalgamated form is:

  my:Derived rdfs:subClassOf [
      owl:intersectionOf (
          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] ) ] .

, the former is simpler and easier to work with in SPARQL. That can ease governance queries, SPIN rules, visualization, etc. (I think Protégé still needs the intersectionOf for e.g. class expressions used in :someValuesFrom .)


> However, I don’t understand your “concatenated form” (hasPart some (A and B)). It is not equivalent to ((hasPart some A ) and (hasPart some B)). So using it as the query expression will yield different than what you get if you use ((hasPart some A ) and (hasPart some B)) as the query expression.
>
> If you can be more specific about the query you were able to make before and the results it returned, and the query you have to make now (and the results it returns), it would help me to understand the issue. (A sample ontology would be helpful.)
>
> Thank you.
>
> With best regards,
> Samson
>
>
> On Mar 6, 2014, at 5:13 AM, Julian Vincent <[hidden email]> wrote:
>
> > It's all there in Protege, as items 7 and 8 under the menu item 'Refactor'.  
> >
> > To illustrate, set up a class and allow it to have 3 very similar subclass axioms - let's say you enter "hasPart some A", "hasPart some B" and "hasPart some C".  These are 3 separate axioms.  Now go to the menu item 'Refactor' and check on 'Amalgamate subclass axioms' and you'll find that the 3 separate axioms you have just entered have been amalgamated into a single (verbose) axiom, strung together with the word "and".  Play a little more . . . highlight this newly amalgamated axiom and generate the closure axiom which will generate the axiom "hasPart only (A or B or C)".  This can't be reduced to separate axioms by checking 'split subclass axioms', but your original 3 axioms will be reformed separated and you can then rewrite them in the same form as the closure axiom - i.e. "hasPart some (A and B and C)" (I will call this the 'concatenated' form.  There may be a proper name for it.  I don't know)  You can then amalgamate both statements as before.  All these forms will be accepted
> >  by the Reasoner (I use FaCT++).
> > So I repeat my question - what, if any, is the advantage of amalgamation?  Why is it made available (but, like several items in the menu) not mentioned in the tutorial?  What is the difference between the verbose and concatenated forms of the amalgamated axioms?
> >
> > This was brought up by my discovery that a search technique I was using with DL Query seems not to be available any more (or is it some quirk of the new Mac OS X 9.2?).  Given the three separate "hasPart . . . " axioms I used to be able to search for a class which contained any two of the axioms by entering (the concatenated form) "hasPart some (A and B)" (or A and C   or  B and C) in the DL Query box, highlight the Execute box just beneath, and get the name(s) of the class(es) containing that combination of axioms, amongst others.  However, now I can't do it. I can enter "hasPart some A and hasPart some B" and get the class(es) returned.  But I can't enter the concatenated form of the axiom into DL Query and expect a useful result if that format is not available in the classes I am querying.  What happened?  As far as I can see there is no logical difference between the separated axioms or the amalgamated axioms, whether in verbose or concatenated form.  
> >
> > If all this seems a bit confusing I suggest you go through this sequence carefully and slowly and experience the inconsistencies.  Do they constitute a bug or do they express a remarkably subtle feature that I am incapable of recognising.  This is quite serious as far as I am concerned, since it would require my changing something like 2 000 groups of axioms if the concatenated query is no longer functional.
> >
> > Julian Vincent
> >
> >
> >
> > On 4 Mar 2014, at 00:27, Csongor Nyulas <[hidden email]> wrote:
> >
> >> Hi Julian,
> >> I am not sure what you mean by "amalgating subclass axioms". Can you give us an example?
> >>
> >> Csongor
> >>
> >> On 03/03/2014 02:47 PM, Julian Vincent wrote:
> >>> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
> >>>
> >>> Julian Vincent
> >>> _______________________________________________
> >>> protege-user mailing list
> >>> [hidden email]
> >>> https://mailman.stanford.edu/mailman/listinfo/protege-user
> >>
> >> _______________________________________________
> >> protege-user mailing list
> >> [hidden email]
> >> https://mailman.stanford.edu/mailman/listinfo/protege-user
> >
> > _______________________________________________
> > protege-user mailing list
> > [hidden email]
> > https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

([hidden email])
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: amalgamating subclass axioms - why?

Julian Vincent-2
OK.  I'll say it again in a different way.

What is the difference (and please be specific - my brain is only small . . . ) between, within a single class (using Protege 4), saying:

Class: Test1
hasPart some A
hasPart some B
hasPart some C

Class: Test2
(hasPart some A) and (hasPart some B) and (hasPart some C)

Class: Test3
hasPart some (A and B and C)

When I enter these classes into a simple ontology (
) the auto-generated closure axiom for Test1 and Test2 is the same, but for Test3 is different.  If I then amalgamate the subclasses, Test1 and Test2 become very similar (except for a layer of brackets) but Test3 is different.  Splitting the axioms to return to the starting position makes Test1 and Test2 identical; Test3 is still different.

What I can't get my head around is that until recently (and I don't know when the change occurred) I could use the format of Test3 to query the format of Test1 (I have about 2 000 classes in the format of Test1, with up to 4 axioms in each class and 40 different objects taking the place of A, B and C in the example here.  I want to find similarities between the 2 000 classes and a new, unclassified, class.).  I can't do that any more.  However, since the axioms in my large ontology equivalent to A, B and C are (obviously, from the above) defining attributes of the classes, I need to be sure that I am defining them properly, even with the closure axioms.  

My (revised) questions:  What's the difference between (Test1, Test2) and Test3?  Does it matter??
And I agree with the comment that the format of Test1 is the easiest to deal with!

Thanks
Julian






On 7 Mar 2014, at 08:44, Eric Prud'hommeaux <[hidden email]> wrote:

> * Samson Tu <[hidden email]> [2014-03-06 16:48-0800]
>> Hi Vincent,
>>
>> Thanks for bringing to my attention these Protege 4 features I haven't used before. I think these splitting and amalgamation are purely syntactic changes. Aside from taste and convenience, I don’t know of any reason to prefer one form or another.
>
> Presuming (and I haven't done the exercise Vincent outlined in his last mail) that the RDF representation of the split form is:
>
>  my:Derived rdfs:subClassOf
>          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
>          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] .
>
> and the amalgamated form is:
>
>  my:Derived rdfs:subClassOf [
>      owl:intersectionOf (
>          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
>          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] ) ] .
>
> , the former is simpler and easier to work with in SPARQL. That can ease governance queries, SPIN rules, visualization, etc. (I think Protégé still needs the intersectionOf for e.g. class expressions used in :someValuesFrom .)
>
>
>> However, I don’t understand your “concatenated form” (hasPart some (A and B)). It is not equivalent to ((hasPart some A ) and (hasPart some B)). So using it as the query expression will yield different than what you get if you use ((hasPart some A ) and (hasPart some B)) as the query expression.
>>
>> If you can be more specific about the query you were able to make before and the results it returned, and the query you have to make now (and the results it returns), it would help me to understand the issue. (A sample ontology would be helpful.)
>>
>> Thank you.
>>
>> With best regards,
>> Samson
>>
>>
>> On Mar 6, 2014, at 5:13 AM, Julian Vincent <[hidden email]> wrote:
>>
>>> It's all there in Protege, as items 7 and 8 under the menu item 'Refactor'.  
>>>
>>> To illustrate, set up a class and allow it to have 3 very similar subclass axioms - let's say you enter "hasPart some A", "hasPart some B" and "hasPart some C".  These are 3 separate axioms.  Now go to the menu item 'Refactor' and check on 'Amalgamate subclass axioms' and you'll find that the 3 separate axioms you have just entered have been amalgamated into a single (verbose) axiom, strung together with the word "and".  Play a little more . . . highlight this newly amalgamated axiom and generate the closure axiom which will generate the axiom "hasPart only (A or B or C)".  This can't be reduced to separate axioms by checking 'split subclass axioms', but your original 3 axioms will be reformed separated and you can then rewrite them in the same form as the closure axiom - i.e. "hasPart some (A and B and C)" (I will call this the 'concatenated' form.  There may be a proper name for it.  I don't know)  You can then amalgamate both statements as before.  All these forms will be accepted
>>> by the Reasoner (I use FaCT++).
>>> So I repeat my question - what, if any, is the advantage of amalgamation?  Why is it made available (but, like several items in the menu) not mentioned in the tutorial?  What is the difference between the verbose and concatenated forms of the amalgamated axioms?
>>>
>>> This was brought up by my discovery that a search technique I was using with DL Query seems not to be available any more (or is it some quirk of the new Mac OS X 9.2?).  Given the three separate "hasPart . . . " axioms I used to be able to search for a class which contained any two of the axioms by entering (the concatenated form) "hasPart some (A and B)" (or A and C   or  B and C) in the DL Query box, highlight the Execute box just beneath, and get the name(s) of the class(es) containing that combination of axioms, amongst others.  However, now I can't do it. I can enter "hasPart some A and hasPart some B" and get the class(es) returned.  But I can't enter the concatenated form of the axiom into DL Query and expect a useful result if that format is not available in the classes I am querying.  What happened?  As far as I can see there is no logical difference between the separated axioms or the amalgamated axioms, whether in verbose or concatenated form.  
>>>
>>> If all this seems a bit confusing I suggest you go through this sequence carefully and slowly and experience the inconsistencies.  Do they constitute a bug or do they express a remarkably subtle feature that I am incapable of recognising.  This is quite serious as far as I am concerned, since it would require my changing something like 2 000 groups of axioms if the concatenated query is no longer functional.
>>>
>>> Julian Vincent
>>>
>>>
>>>
>>> On 4 Mar 2014, at 00:27, Csongor Nyulas <[hidden email]> wrote:
>>>
>>>> Hi Julian,
>>>> I am not sure what you mean by "amalgating subclass axioms". Can you give us an example?
>>>>
>>>> Csongor
>>>>
>>>> On 03/03/2014 02:47 PM, Julian Vincent wrote:
>>>>> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
>>>>>
>>>>> Julian Vincent
>>>>> _______________________________________________
>>>>> protege-user mailing list
>>>>> [hidden email]
>>>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>>>
>>>> _______________________________________________
>>>> protege-user mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>>
>>> _______________________________________________
>>> protege-user mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>
>> _______________________________________________
>> protege-user mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> ([hidden email])
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user

Test.owl (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: amalgamating subclass axioms - why?

Filipe Santana

Hi Julian,

This one is quite simples to answer.

When you say hasPart some (a and b and c), it means (from DL) that all 3 classes must apear and share instances (if you relembre set theory), and also with the superclass you are specifying.

In the other cases, the classes must share instances only with the superclass.

Because of that, you can retrieve results with cases 1 and 2 (they certainly are the same thing) and nota with the 3rd.

I hope it helps.

Filipe

Em 07/03/2014 07:12, "Julian Vincent" <[hidden email]> escreveu:
OK.  I'll say it again in a different way.

What is the difference (and please be specific - my brain is only small . . . ) between, within a single class (using Protege 4), saying:

Class: Test1
hasPart some A
hasPart some B
hasPart some C

Class: Test2
(hasPart some A) and (hasPart some B) and (hasPart some C)

Class: Test3
hasPart some (A and B and C)

When I enter these classes into a simple ontology (
) the auto-generated closure axiom for Test1 and Test2 is the same, but for Test3 is different.  If I then amalgamate the subclasses, Test1 and Test2 become very similar (except for a layer of brackets) but Test3 is different.  Splitting the axioms to return to the starting position makes Test1 and Test2 identical; Test3 is still different.

What I can't get my head around is that until recently (and I don't know when the change occurred) I could use the format of Test3 to query the format of Test1 (I have about 2 000 classes in the format of Test1, with up to 4 axioms in each class and 40 different objects taking the place of A, B and C in the example here.  I want to find similarities between the 2 000 classes and a new, unclassified, class.).  I can't do that any more.  However, since the axioms in my large ontology equivalent to A, B and C are (obviously, from the above) defining attributes of the classes, I need to be sure that I am defining them properly, even with the closure axioms.

My (revised) questions:  What's the difference between (Test1, Test2) and Test3?  Does it matter??
And I agree with the comment that the format of Test1 is the easiest to deal with!

Thanks
Julian






On 7 Mar 2014, at 08:44, Eric Prud'hommeaux <[hidden email]> wrote:

> * Samson Tu <[hidden email]> [2014-03-06 16:48-0800]
>> Hi Vincent,
>>
>> Thanks for bringing to my attention these Protege 4 features I haven't used before. I think these splitting and amalgamation are purely syntactic changes. Aside from taste and convenience, I don’t know of any reason to prefer one form or another.
>
> Presuming (and I haven't done the exercise Vincent outlined in his last mail) that the RDF representation of the split form is:
>
>  my:Derived rdfs:subClassOf
>          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
>          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] .
>
> and the amalgamated form is:
>
>  my:Derived rdfs:subClassOf [
>      owl:intersectionOf (
>          [ :onProperty my:p1 ; :someValuesFrom my:C1 ] ,
>          [ :onProperty my:p2 ; :someValuesFrom my:C2 ] ) ] .
>
> , the former is simpler and easier to work with in SPARQL. That can ease governance queries, SPIN rules, visualization, etc. (I think Protégé still needs the intersectionOf for e.g. class expressions used in :someValuesFrom .)
>
>
>> However, I don’t understand your “concatenated form” (hasPart some (A and B)). It is not equivalent to ((hasPart some A ) and (hasPart some B)). So using it as the query expression will yield different than what you get if you use ((hasPart some A ) and (hasPart some B)) as the query expression.
>>
>> If you can be more specific about the query you were able to make before and the results it returned, and the query you have to make now (and the results it returns), it would help me to understand the issue. (A sample ontology would be helpful.)
>>
>> Thank you.
>>
>> With best regards,
>> Samson
>>
>>
>> On Mar 6, 2014, at 5:13 AM, Julian Vincent <[hidden email]> wrote:
>>
>>> It's all there in Protege, as items 7 and 8 under the menu item 'Refactor'.
>>>
>>> To illustrate, set up a class and allow it to have 3 very similar subclass axioms - let's say you enter "hasPart some A", "hasPart some B" and "hasPart some C".  These are 3 separate axioms.  Now go to the menu item 'Refactor' and check on 'Amalgamate subclass axioms' and you'll find that the 3 separate axioms you have just entered have been amalgamated into a single (verbose) axiom, strung together with the word "and".  Play a little more . . . highlight this newly amalgamated axiom and generate the closure axiom which will generate the axiom "hasPart only (A or B or C)".  This can't be reduced to separate axioms by checking 'split subclass axioms', but your original 3 axioms will be reformed separated and you can then rewrite them in the same form as the closure axiom - i.e. "hasPart some (A and B and C)" (I will call this the 'concatenated' form.  There may be a proper name for it.  I don't know)  You can then amalgamate both statements as before.  All these forms will be accepted
>>> by the Reasoner (I use FaCT++).
>>> So I repeat my question - what, if any, is the advantage of amalgamation?  Why is it made available (but, like several items in the menu) not mentioned in the tutorial?  What is the difference between the verbose and concatenated forms of the amalgamated axioms?
>>>
>>> This was brought up by my discovery that a search technique I was using with DL Query seems not to be available any more (or is it some quirk of the new Mac OS X 9.2?).  Given the three separate "hasPart . . . " axioms I used to be able to search for a class which contained any two of the axioms by entering (the concatenated form) "hasPart some (A and B)" (or A and C   or  B and C) in the DL Query box, highlight the Execute box just beneath, and get the name(s) of the class(es) containing that combination of axioms, amongst others.  However, now I can't do it. I can enter "hasPart some A and hasPart some B" and get the class(es) returned.  But I can't enter the concatenated form of the axiom into DL Query and expect a useful result if that format is not available in the classes I am querying.  What happened?  As far as I can see there is no logical difference between the separated axioms or the amalgamated axioms, whether in verbose or concatenated form.
>>>
>>> If all this seems a bit confusing I suggest you go through this sequence carefully and slowly and experience the inconsistencies.  Do they constitute a bug or do they express a remarkably subtle feature that I am incapable of recognising.  This is quite serious as far as I am concerned, since it would require my changing something like 2 000 groups of axioms if the concatenated query is no longer functional.
>>>
>>> Julian Vincent
>>>
>>>
>>>
>>> On 4 Mar 2014, at 00:27, Csongor Nyulas <[hidden email]> wrote:
>>>
>>>> Hi Julian,
>>>> I am not sure what you mean by "amalgating subclass axioms". Can you give us an example?
>>>>
>>>> Csongor
>>>>
>>>> On 03/03/2014 02:47 PM, Julian Vincent wrote:
>>>>> It seems to me that it's easiest to enter subclass axioms separately.  What is the advantage, if any, of amalgamating them?  Is it possible to amalgamate subclass axioms in only a part of the ontology?
>>>>>
>>>>> Julian Vincent
>>>>> _______________________________________________
>>>>> protege-user mailing list
>>>>> [hidden email]
>>>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>>>
>>>> _______________________________________________
>>>> protege-user mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>>
>>> _______________________________________________
>>> protege-user mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>>
>> _______________________________________________
>> protege-user mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-user
>
> --
> -ericP
>
> office: <a href="tel:%2B1.617.599.3509" value="+16175993509">+1.617.599.3509
> mobile: <a href="tel:%2B33.6.80.80.35.59" value="+33680803559">+33.6.80.80.35.59
>
> ([hidden email])
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: amalgamating subclass axioms - why?

Olivier Dameron
In reply to this post by Julian Vincent-2
Hello Julian

On 03/07/2014 11:11 AM, Julian Vincent wrote:

> What is the difference (and please be specific - my brain is only small . . . ) between, within a single class (using Protege 4), saying:
>
> Class: Test1
> hasPart some A
> hasPart some B
> hasPart some C
>
> Class: Test2
> (hasPart some A) and (hasPart some B) and (hasPart some C)
>
> Class: Test3
> hasPart some (A and B and C)

Test1 and Test2 are equivalent (assuming A, B and C are disjoint, Test1
and Test2 have at least three parts)

Test3 has at least one part that is simultaneously an instance of A, B and C

An example for Test1 would be
Knife hasPart some Blade + hasPart some Handle

An example for Test3 would be something with a plastic handle :
hasPart (Handle and MadeOfPlastic)

If A, B and C are disfoint, Test3 is inconsistent ; otherwise it is a
subclass of Test1 : it does have a part that is a A, a part that is a B
(actually it is the same part), etc

olivier
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user