From: Philippe Rocca-S. <ro...@eb...> - 2007-11-29 09:59:50
|
Hi Melanie, Thanks for the reminder :) Just for information, Melanie and myself had an informal discussion about the 'utilizes' relation, that is should we keep general or should we create specialized flavour such as 'utilizes_intrument', 'utilizes_algorithm', 'utilizes_reagent' and so forth. I don't have any preconception for either or the other option however the summary of the discussion with Melanie was the following (Melanie please, correct me if I misrepresent our email exchange !) 1. We might end-up with a huge number of relations. Is that really needed? What do we gain ? 2. Taking the example of 'utilizes', every time (it seems) a utilizes relation is necessary, the range of the relation will be defined is Protege. So what is the added value of having ? Class=Data transformation /utilizes_algorithm/ 'filler=Class Algorithm' v Class=Data transformation /utilizes/ 'filler=Class Algorithm' Again, here we simply looking for more explanations and reasons in order to understand a rationale for 'specializing relations'. Once this is established, all other branches could have a set of rules/principles to work. I was under the impression (probably a wrong one) that we should have been working with the obo-rel relations and when identifying a new need, put a formal request for addition to OBO-rel. By Formal, I mean here address the All/Some cases as described in the article. Again, If we could clarify the issue, that would be a nice outcome. Regarding the terms submitted, I'll create the relevant classes and If metadata can not resolved or is missing, will contact the Data Transformation branch again. thx P. Melanie Courtot wrote: > Hi Philippe, > > Following previous discussions, please find below a summary of action > regarding data_transformation towards the plan branch. We thought that the > description of the algorithms would be better if based on a citation > providing full description. > Let me know if anything seems unclear or if you have any comments! > > Thanks, > Melanie > > > AI: Coordinate interaction with the plan branch, all algorithms and other > terms. > In progress. We are trying to work out the relation "utilizes" and others > in collaboration with Philippe. > > AI: According to decisions after TBD, possibly submit > probabilistic_algorithm (with synonym stochastic_algorithm?) to the plan > branch. > > Decision from the last data_transformation conference call: Tina will pass > on to PATO the > terms stochastic and deterministic to be added as qualities. > > There is already a relationship "has_quality" however its domain is > independant_continuant (it's range is quality so that's fine). Plan is a > dependant_continuant, so it wouldn't be possible to say "algorithm > has_quality stochastic". To be checked. > In addition, Elisabetta thinks that adding has_quality stochastic to an > algorithm, the definition of stochastic might be to broad to be applicable > in this case, or lack precision. To be checked further on (after > submission of the terms to PATO and their reply) > > > AI: Pass to the plan branch: Genetic > Algorithm, Boosting algorithm, Bootstrap algorithm, Weighted Majority > Algorithm, Cooley and Tukey Fast Fourier Algorithm > > Evolutionary Algorithm (term added to be a parent of Genetic Algorithm) > An evolutionary Algorithm is a generic population-based metaheuristic > optimization algorithm. The methodology is described at > http://en.wikipedia.org/wiki/Evolutionary_algorithm > > Genetic Algorithm > A genetic algorithm (GA) is a search technique used in computing to find > true or approximate solutions to optimization and search problems source. > The methodology is described at > http://en.wikipedia.org/wiki/Genetic_algorithm > > Boosting Algorithm > A boosting Algorithm is a machine learning meta-algorithm for performing > supervised learning. Boosting occurs in stages, by incrementally adding to > the current learned function. At every stage, a weak learner (i.e., one > that has an accuracy greater than chance) is trained with the data. The > output of the weak learner is then added to the learned function, with > some strength (proportional to how accurate the weak learner is). Then, > the data is reweighted: examples that the current learned function gets > wrong are "boosted" in importance, so that future weak learners will > attempt to fix the errors. The methodology is described at > http://en.wikipedia.org/wiki/Boosting > > Bootsrap Aggregating (name changed from Bootstrap Algorithm to be > consistent with he definition and the commonly used term) > bootstrap aggregating is a meta-algorithm to improve classification and > regression models in terms of stability and classification accuracy. > The methodology is described at > http://en.wikipedia.org/wiki/Bootstrap_aggregating > add bagging as alternative term. > > > Weighted Majority Algorithm > In machine learning, Weighted Majority Algorithm (WMA) is a meta-learning > algorithm used to construct a compound algorithm from a pool of prediction > algorithms, which could be any type of learning algorithms, classifiers, > or even real human experts. The algorithm assumes that we have no prior > knowledge about the accuracy of the algorithms in the pool, but there are > sufficient reasons to believe that one or more will perform well. > The methodology is described at > http://en.wikipedia.org/wiki/Weighted_Majority_Algorithm > > Fast Fourier Transform (added to be a parent of Cooley > and Tukey) > Fast Fourier Transform is an efficient algorithm to compute the discrete > Fourier transform (DFT) and its inverse. > add alternative term FFT > The methodology is described at > http://en.wikipedia.org/wiki/Fast_Fourier_transform > > Cooley and Tukey Fast Fourier Algorithm > The Cooley-Tukey algorithm is the most common fast Fourier transform (FFT) > algorithm. It re-expresses the discrete Fourier transform (DFT) of an > arbitrary composite size N = N1N2 in terms of smaller DFTs of sizes N1 and > N2, recursively, in order to reduce the computation time to O(N log N) for > highly-composite N (smooth numbers). > It works significantly faster than other Fourier algorithm provided the > size of the problem is a power of 2. > The methodology is described at > http://en.wikipedia.org/wiki/Cooley-Tukey_FFT_algorithm > -- **************************************************************** Philippe Rocca-Serra (Ph.D) NET Project - Technical Coordinator http://www.ebi.ac.uk/net-project EBI- The European Bioinformatics Institute EMBL Outstation Hinxton Wellcome Trust Genome Campus CB10 1SD Cambridge, UK email: ro...@eb... Tel: +44 (0) 1223 492 553 Fax: +44 (0) 1223 494 468 European Nutrigenomics Organization http://www.nugo.org **************************************************************** |
From: Liju F. <lij...@gm...> - 2007-11-29 15:50:23
|
Hi, Philippe. Please see below for comments. Cheers, Liju On Nov 29, 2007 4:59 AM, Philippe Rocca-Serra <ro...@eb...> wrote: > Hi Melanie, > > Thanks for the reminder :) > > Just for information, Melanie and myself had an informal discussion > about the 'utilizes' relation, that is should we keep general or should > we create specialized flavour such > as 'utilizes_intrument', 'utilizes_algorithm', 'utilizes_reagent' and so > forth. > I don't have any preconception for either or the other option however > the summary of the discussion with Melanie was the following (Melanie > please, correct me if I misrepresent our email exchange !) > > 1. We might end-up with a huge number of relations. Is that really > needed? What do we gain ? Liju: Probably there is no need and won't gain much. The key is to have relations simple and let the reasoner do the inferencing. > 2. Taking the example of 'utilizes', every time (it seems) a utilizes > relation is necessary, the range of the relation will be defined is > Protege. > So what is the added value of having ? > Class=Data transformation /utilizes_algorithm/ 'filler=Class Algorithm' > v > Class=Data transformation /utilizes/ 'filler=Class Algorithm' > > Again, here we simply looking for more explanations and reasons in order > to understand a rationale for 'specializing relations'. > Once this is established, all other branches could have a set of > rules/principles to work. Liju: Specializing relations probably won't be necessary since the reasoner can do the inferencing. However, we have made exceptions when the protocol application branch made the requests for utilizes_instrument and utilizes_reagent for users to search by the specialized relations. Thus, utilizes_instrument and utilizes_reagent are already in the OBI owl file and have been submitted to OBI-rel as sub-relations of has_participant. The domain of both is process. The range of utilizes_reagent is "continuant has_role reagent_role". The range of utilizes_instrument is instrument. As to utilizes_algorithm for data transformation, we will do the same if the class algorithm is somewhere in OBI. > I was under the impression (probably a wrong one) that we should have > been working with the obo-rel relations and when identifying a new need, > put a formal request for addition to OBO-rel. By Formal, I mean here > address the All/Some cases as described in the article. Again, If we > could clarify the issue, that would be a nice outcome. Liju: My understanding is that the OBI-relations branch collects the relation requests from all other OBI branches such as utilizes, looks for common relation needs among branches, defines them (give a standard definition, identify subject and object, assign some/all, etc), and submit to OBO relations ontology on behalf of the OBI branches. The relations branch has made some progress though slow. Liju: Please submit your branch relations to the relations branch mailing list to assist us in the process. obi...@li.... We also have a excel spreadsheet on google. https://spreadsheets.google.com/ccc?key=p4ViR8BgYUWaAG1b5IaxcJw&hl=en&pli=1 > Regarding the terms submitted, I'll create the relevant classes and If > metadata can not resolved or is missing, will contact the Data > Transformation branch again. > > thx > > P. > > Melanie Courtot wrote: > > Hi Philippe, > > > > Following previous discussions, please find below a summary of action > > regarding data_transformation towards the plan branch. We thought that the > > description of the algorithms would be better if based on a citation > > providing full description. > > Let me know if anything seems unclear or if you have any comments! > > > > Thanks, > > Melanie > > > > > > AI: Coordinate interaction with the plan branch, all algorithms and other > > terms. > > In progress. We are trying to work out the relation "utilizes" and others > > in collaboration with Philippe. > > > > AI: According to decisions after TBD, possibly submit > > probabilistic_algorithm (with synonym stochastic_algorithm?) to the plan > > branch. > > > > Decision from the last data_transformation conference call: Tina will pass > > on to PATO the > > terms stochastic and deterministic to be added as qualities. > > > > There is already a relationship "has_quality" however its domain is > > independant_continuant (it's range is quality so that's fine). Plan is a > > dependant_continuant, so it wouldn't be possible to say "algorithm > > has_quality stochastic". To be checked. > > In addition, Elisabetta thinks that adding has_quality stochastic to an > > algorithm, the definition of stochastic might be to broad to be applicable > > in this case, or lack precision. To be checked further on (after > > submission of the terms to PATO and their reply) > > > > > > AI: Pass to the plan branch: Genetic > > Algorithm, Boosting algorithm, Bootstrap algorithm, Weighted Majority > > Algorithm, Cooley and Tukey Fast Fourier Algorithm > > > > Evolutionary Algorithm (term added to be a parent of Genetic Algorithm) > > An evolutionary Algorithm is a generic population-based metaheuristic > > optimization algorithm. The methodology is described at > > http://en.wikipedia.org/wiki/Evolutionary_algorithm > > > > Genetic Algorithm > > A genetic algorithm (GA) is a search technique used in computing to find > > true or approximate solutions to optimization and search problems source. > > The methodology is described at > > http://en.wikipedia.org/wiki/Genetic_algorithm > > > > Boosting Algorithm > > A boosting Algorithm is a machine learning meta-algorithm for performing > > supervised learning. Boosting occurs in stages, by incrementally adding to > > the current learned function. At every stage, a weak learner (i.e., one > > that has an accuracy greater than chance) is trained with the data. The > > output of the weak learner is then added to the learned function, with > > some strength (proportional to how accurate the weak learner is). Then, > > the data is reweighted: examples that the current learned function gets > > wrong are "boosted" in importance, so that future weak learners will > > attempt to fix the errors. The methodology is described at > > http://en.wikipedia.org/wiki/Boosting > > > > Bootsrap Aggregating (name changed from Bootstrap Algorithm to be > > consistent with he definition and the commonly used term) > > bootstrap aggregating is a meta-algorithm to improve classification and > > regression models in terms of stability and classification accuracy. > > The methodology is described at > > http://en.wikipedia.org/wiki/Bootstrap_aggregating > > add bagging as alternative term. > > > > > > Weighted Majority Algorithm > > In machine learning, Weighted Majority Algorithm (WMA) is a meta-learning > > algorithm used to construct a compound algorithm from a pool of prediction > > algorithms, which could be any type of learning algorithms, classifiers, > > or even real human experts. The algorithm assumes that we have no prior > > knowledge about the accuracy of the algorithms in the pool, but there are > > sufficient reasons to believe that one or more will perform well. > > The methodology is described at > > http://en.wikipedia.org/wiki/Weighted_Majority_Algorithm > > > > Fast Fourier Transform (added to be a parent of Cooley > > and Tukey) > > Fast Fourier Transform is an efficient algorithm to compute the discrete > > Fourier transform (DFT) and its inverse. > > add alternative term FFT > > The methodology is described at > > http://en.wikipedia.org/wiki/Fast_Fourier_transform > > > > Cooley and Tukey Fast Fourier Algorithm > > The Cooley-Tukey algorithm is the most common fast Fourier transform (FFT) > > algorithm. It re-expresses the discrete Fourier transform (DFT) of an > > arbitrary composite size N = N1N2 in terms of smaller DFTs of sizes N1 and > > N2, recursively, in order to reduce the computation time to O(N log N) for > > highly-composite N (smooth numbers). > > It works significantly faster than other Fourier algorithm provided the > > size of the problem is a power of 2. > > The methodology is described at > > http://en.wikipedia.org/wiki/Cooley-Tukey_FFT_algorithm > > > > > -- > **************************************************************** > Philippe Rocca-Serra (Ph.D) > NET Project - Technical Coordinator > http://www.ebi.ac.uk/net-project > > EBI- The European Bioinformatics Institute > EMBL Outstation Hinxton > > Wellcome Trust Genome Campus > CB10 1SD Cambridge, UK > > email: ro...@eb... > Tel: +44 (0) 1223 492 553 > Fax: +44 (0) 1223 494 468 > > European Nutrigenomics Organization > http://www.nugo.org > > **************************************************************** > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > -- Liju Fan, Ph.D. Ontology Workshop, LLC P.O. Box 182 Columbia, MD 21045-9998 Phone: (410) 880-8988 Mobile: (443) 745-7412 email: lij...@gm... |
From: Matthew P. <mat...@nc...> - 2007-11-29 22:01:38
|
On Thursday 29 November 2007, Liju Fan wrote: > Liju: Specializing relations probably won't be necessary since the > reasoner can do the inferencing. However, we have made exceptions > when the protocol application branch made the requests for > utilizes_instrument and utilizes_reagent for users to search by the > specialized relations. Thus, utilizes_instrument and utilizes_reagent > are already in the OBI owl file and have been submitted to OBI-rel as > sub-relations of has_participant. The domain of both is process. > The range of utilizes_reagent is "continuant has_role reagent_role". > The range of utilizes_instrument is instrument. As to > utilizes_algorithm for data transformation, we will do the same if the > class algorithm is somewhere in OBI. Hi, I have no personal issue with utilizes_instrument vs utilizes_reagent vs has_participant. However, OWL may. If we have something like: has_participant myInstrument instanceOf(myInstrument Instrument) range(utilizes_instrument Instrument) then OWL reasoners will be unable to infer utilizes_instrument myInstrument regardless of any domain and range constraints you add. This is because in OWL, you can not state disjointness and covering constraints between sub-relations, only between classes. That is, you can't tell OWL that every filler has_participant that is an Instrument must be a filler of utlilizes_instrument, because OWL will assume that either has_participant directly, or some other sub-relation could have been intended. If you require this inference to be made, then this is a problem. If you require people to always describe participation in the most specific terms possible, then you will be OK. So, is it intended that every time you have a has_participant Instrument, that you also utilizes_instrument? Matthew |
From: Bjoern P. <bp...@li...> - 2007-11-29 23:07:07
|
There are things such as antibodies that can be e.g. reagents and study objects. Therefore antibodies can participate in multiple roles in a protocol_application. The idea behind the subrelations of 'utilizes' was to make this simpler to write. We were aware that this duplicates the role hierarchy, but thought it would not hurt. -----Original Message----- From: obi...@li... [mailto:obi...@li...] On Behalf Of Matthew Pocock Sent: Thursday, November 29, 2007 2:01 PM To: obi...@li... Cc: OBI Relations Mailing List; Obi...@li... Subject: Re: [Obi-devel] new terms for PLAN from data_transformation On Thursday 29 November 2007, Liju Fan wrote: > Liju: Specializing relations probably won't be necessary since the > reasoner can do the inferencing. However, we have made exceptions > when the protocol application branch made the requests for > utilizes_instrument and utilizes_reagent for users to search by the > specialized relations. Thus, utilizes_instrument and utilizes_reagent > are already in the OBI owl file and have been submitted to OBI-rel as > sub-relations of has_participant. The domain of both is process. > The range of utilizes_reagent is "continuant has_role reagent_role". > The range of utilizes_instrument is instrument. As to > utilizes_algorithm for data transformation, we will do the same if the > class algorithm is somewhere in OBI. Hi, I have no personal issue with utilizes_instrument vs utilizes_reagent vs has_participant. However, OWL may. If we have something like: has_participant myInstrument instanceOf(myInstrument Instrument) range(utilizes_instrument Instrument) then OWL reasoners will be unable to infer utilizes_instrument myInstrument regardless of any domain and range constraints you add. This is because in OWL, you can not state disjointness and covering constraints between sub-relations, only between classes. That is, you can't tell OWL that every filler has_participant that is an Instrument must be a filler of utlilizes_instrument, because OWL will assume that either has_participant directly, or some other sub-relation could have been intended. If you require this inference to be made, then this is a problem. If you require people to always describe participation in the most specific terms possible, then you will be OK. So, is it intended that every time you have a has_participant Instrument, that you also utilizes_instrument? Matthew ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Obi-devel mailing list Obi...@li... https://lists.sourceforge.net/lists/listinfo/obi-devel |
From: Alan R. <ala...@gm...> - 2007-11-30 01:01:24
|
Just because an instrument participates in a process doesn't mean it is realizing the instrument's role. So I may have a scanner, which is an instrument, but it participates only in that I use it as a table. One would use utilizes_instrument when the scanner is scanning something in the process. The utilizes_instrument (should) have the additional implications that the domain is a process that realizes the instrument's role, and that range (the purported instrument) has some instrument role. I thought we had put in something to that effect, but on inspection of the file it seems we only have some documentation, and probably not adequate docs. Hopefully that explains the motivation and the difference. -Alan On Nov 29, 2007, at 5:01 PM, Matthew Pocock wrote: > Hi, > > I have no personal issue with utilizes_instrument vs > utilizes_reagent vs > has_participant. However, OWL may. If we have something like: > > has_participant myInstrument > instanceOf(myInstrument Instrument) > range(utilizes_instrument Instrument) > > then OWL reasoners will be unable to infer > > utilizes_instrument myInstrument > > regardless of any domain and range constraints you add. This is > because in > OWL, you can not state disjointness and covering constraints between > sub-relations, only between classes. That is, you can't tell OWL > that every > filler has_participant that is an Instrument must be a filler of > utlilizes_instrument, because OWL will assume that either > has_participant > directly, or some other sub-relation could have been intended. > > If you require this inference to be made, then this is a problem. > If you > require people to always describe participation in the most > specific terms > possible, then you will be OK. > > So, is it intended that every time you have a has_participant > Instrument, that > you also utilizes_instrument? > > Matthew |
From: Matthew P. <mat...@nc...> - 2007-11-30 08:23:39
|
On Friday 30 November 2007, Alan Ruttenberg wrote: > Just because an instrument participates in a process doesn't mean it > is realizing the instrument's role. I quite agree - consider a scales being used to weigh a lazer. > So I may have a scanner, which is an instrument, but it participates > only in that I use it as a table. > One would use utilizes_instrument when the scanner is scanning > something in the process. OK, this is clear. However, I don't think it has the entailments you intend... > The utilizes_instrument (should) have the additional implications > that the domain is a process that realizes the instrument's role, and > that range (the purported instrument) has some instrument role. Well, clearly this is so. However, I don't think this changes the inference issue, and in addition, now you are stating the knowledge twice. Firstly, you have the role and its realization as they pertain to the instrument and the process. Seccondly, you have a specialised relation. Either one is sufficient to know what is participating in the activity in what capacity. However, there is an a-symmetry here. If you state it in terms of the relation, you will be able to infer (given the domain/range restrictions you envisage) it in terms of roles. If you state it in terms of roles, you will be unable to infer it in terms of relations. So, given something like: Process p Instrument i SpecificRole r domain(utilizes_instrument Process) range(utilizes_instrument Instrument) p has_participant i p realizes r i bears r We can not infer: p utilizes_instrument i Is this intended behavior? > I thought we had put in something to that effect, but on inspection > of the file it seems we only have some documentation, and probably > not adequate docs. > > Hopefully that explains the motivation and the difference. It explains it perfectly. Could I sugest that what we really require is the ability to use a different term ("has participant" vs "utilizes instrument") for a single relation (has_participant) depending on what it is relating, rather than a sub-relation? I understand that support for situational terminology is just as absent from OWL as reasoning over properties. However, the rout traveled so far seems to be a terminological one represented directly in the relations with unfortunate side-effects in the reasoning. > > -Alan Matthew |
From: Alan R. <ala...@gm...> - 2007-11-30 09:28:01
|
On Nov 30, 2007, at 3:23 AM, Matthew Pocock wrote: > On Friday 30 November 2007, Alan Ruttenberg wrote: >> Just because an instrument participates in a process doesn't mean it >> is realizing the instrument's role. > > I quite agree - consider a scales being used to weigh a lazer. > >> So I may have a scanner, which is an instrument, but it participates >> only in that I use it as a table. >> One would use utilizes_instrument when the scanner is scanning >> something in the process. > > OK, this is clear. However, I don't think it has the entailments you > intend... You mean the current version in the svn?(agreed) Or the idea in general?(not sure what you mean) >> The utilizes_instrument (should) have the additional implications >> that the domain is a process that realizes the instrument's role, and >> that range (the purported instrument) has some instrument role. > > Well, clearly this is so. However, I don't think this changes the > inference > issue, and in addition, now you are stating the knowledge twice. > Firstly, you > have the role and its realization as they pertain to the instrument > and the > process. Secondly, you have a specialised relation. Yes, but by using the relation, with appropriate domain, range and possibly other axioms, we can get the other part for free. > Either one is sufficient > to know what is participating in the activity in what capacity. > However, > there is an a-symmetry here. If you state it in terms of the > relation, you > will be able to infer (given the domain/range restrictions you > envisage) it > in terms of roles. If you state it in terms of roles, you will be > unable to > infer it in terms of relations. > > So, given something like: > > Process p > Instrument i > SpecificRole r > domain(utilizes_instrument Process) > range(utilizes_instrument Instrument) > > p has_participant i > p realizes r > i bears r > > We can not infer: > > p utilizes_instrument i > > Is this intended behavior? It is suboptimal, but not devastating. We still get the benefit of the concise statement using the relationship, and a set of inferences for things that we would have to state over and over again if we didn't use the relationship. We have to be a bit more careful if we want to recover all cases of the relationship in the query. However, even if so, we are still ahead of the game, as we would have had to do the harder query anyways if we didn't have the specific relation. I have to think about whether we can recover some of what we want using gcis, or new features of OWL 1.1 - that may be possible. >> I thought we had put in something to that effect, but on inspection >> of the file it seems we only have some documentation, and probably >> not adequate docs. >> >> Hopefully that explains the motivation and the difference. > > It explains it perfectly. Could I sugest that what we really require > is the > ability to use a different term ("has participant" vs "utilizes > instrument") > for a single relation (has_participant) depending on what it is > relating, > rather than a sub-relation? explain? > I understand that support for situational > terminology is just as absent from OWL as reasoning over properties. > However, > the rout traveled so far seems to be a terminological one represented > directly in the relations with unfortunate side-effects in the > reasoning. > >> >> -Alan > > Matthew |
From: frank g. <Fra...@nc...> - 2007-11-30 14:05:27
|
Hi, I still don't see how this is more efficient than having the has_participant relation with an instrument performing a role/function. What does utilises_instrument give you other than a human readable relation conflating the role and the relation? Frank On Nov 30, 2007 9:28 AM, Alan Ruttenberg <ala...@gm...> wrote: > > On Nov 30, 2007, at 3:23 AM, Matthew Pocock wrote: > > > On Friday 30 November 2007, Alan Ruttenberg wrote: > >> Just because an instrument participates in a process doesn't mean it > >> is realizing the instrument's role. > > > > I quite agree - consider a scales being used to weigh a lazer. > > > >> So I may have a scanner, which is an instrument, but it participates > >> only in that I use it as a table. > >> One would use utilizes_instrument when the scanner is scanning > >> something in the process. > > > > OK, this is clear. However, I don't think it has the entailments you > > intend... > > You mean the current version in the svn?(agreed) Or the idea in > general?(not sure what you mean) > > >> The utilizes_instrument (should) have the additional implications > >> that the domain is a process that realizes the instrument's role, and > >> that range (the purported instrument) has some instrument role. > > > > Well, clearly this is so. However, I don't think this changes the > > inference > > issue, and in addition, now you are stating the knowledge twice. > > Firstly, you > > have the role and its realization as they pertain to the instrument > > and the > > process. Secondly, you have a specialised relation. > Yes, but by using the relation, with appropriate domain, range and > possibly other axioms, we can get the other part for free. > > Either one is sufficient > > to know what is participating in the activity in what capacity. > > However, > > there is an a-symmetry here. If you state it in terms of the > > relation, you > > will be able to infer (given the domain/range restrictions you > > envisage) it > > in terms of roles. If you state it in terms of roles, you will be > > unable to > > infer it in terms of relations. > > > > So, given something like: > > > > Process p > > Instrument i > > SpecificRole r > > domain(utilizes_instrument Process) > > range(utilizes_instrument Instrument) > > > > p has_participant i > > p realizes r > > i bears r > > > > We can not infer: > > > > p utilizes_instrument i > > > > Is this intended behavior? > > It is suboptimal, but not devastating. We still get the benefit of the > concise statement using the relationship, and a set of inferences for > things that we would have to state over and over again if we didn't > use the relationship. We have to be a bit more careful if we want to > recover all cases of the relationship in the query. However, even if > so, we are still ahead of the game, as we would have had to do the > harder query anyways if we didn't have the specific relation. I have > to think about whether we can recover some of what we want using gcis, > or new features of OWL 1.1 - that may be possible. > > >> I thought we had put in something to that effect, but on inspection > >> of the file it seems we only have some documentation, and probably > >> not adequate docs. > >> > >> Hopefully that explains the motivation and the difference. > > > > It explains it perfectly. Could I sugest that what we really require > > is the > > ability to use a different term ("has participant" vs "utilizes > > instrument") > > for a single relation (has_participant) depending on what it is > > relating, > > rather than a sub-relation? > explain? > > I understand that support for situational > > terminology is just as absent from OWL as reasoning over properties. > > However, > > the rout traveled so far seems to be a terminological one represented > > directly in the relations with unfortunate side-effects in the > > reasoning. > > > >> > >> -Alan > > > > Matthew > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > -- Frank Gibson Research Associate Room 2.19, Devonshire Building School of Computing Science, University of Newcastle upon Tyne, Newcastle upon Tyne, NE1 7RU United Kingdom Telephone: +44-191-246-4933 Fax: +44-191-246-4905 |
From: Allyson L. <a.l...@ne...> - 2007-11-30 14:14:18
|
I agree with Frank here, though I feel a little Friday-confused, and I may get something wrong in the example below. We should just have "utilizes", and then have roles for the thing being utilized, e.g. protocolX utilizes materialY protocolX utilizes instrumentZ instrumentZ hasRole imaging materialY hasRole reagent That way we can perform inference over the role classes, and we don't have to worry about the potential problem matt mentioned about not being able to infer over properties. By knowing that "protocolX utilizes (instrumentZ hasRole imaging)", we can learn that instrumentZ is in fact an instrument via restrictions on the imaging class? :) allyson On 11/30/07, frank gibson <Fra...@nc...> wrote: > > Hi, > > I still don't see how this is more efficient than having the > has_participant relation with an instrument performing a role/function. What > does utilises_instrument give you other than a human readable relation > conflating the role and the relation? > > Frank > > On Nov 30, 2007 9:28 AM, Alan Ruttenberg <ala...@gm...> wrote: > > > > > On Nov 30, 2007, at 3:23 AM, Matthew Pocock wrote: > > > > > On Friday 30 November 2007, Alan Ruttenberg wrote: > > >> Just because an instrument participates in a process doesn't mean it > > >> is realizing the instrument's role. > > > > > > I quite agree - consider a scales being used to weigh a lazer. > > > > > >> So I may have a scanner, which is an instrument, but it participates > > >> only in that I use it as a table. > > >> One would use utilizes_instrument when the scanner is scanning > > >> something in the process. > > > > > > OK, this is clear. However, I don't think it has the entailments you > > > intend... > > > > You mean the current version in the svn?(agreed) Or the idea in > > general?(not sure what you mean) > > > > >> The utilizes_instrument (should) have the additional implications > > >> that the domain is a process that realizes the instrument's role, and > > >> that range (the purported instrument) has some instrument role. > > > > > > Well, clearly this is so. However, I don't think this changes the > > > inference > > > issue, and in addition, now you are stating the knowledge twice. > > > Firstly, you > > > have the role and its realization as they pertain to the instrument > > > and the > > > process. Secondly, you have a specialised relation. > > Yes, but by using the relation, with appropriate domain, range and > > possibly other axioms, we can get the other part for free. > > > Either one is sufficient > > > to know what is participating in the activity in what capacity. > > > However, > > > there is an a-symmetry here. If you state it in terms of the > > > relation, you > > > will be able to infer (given the domain/range restrictions you > > > envisage) it > > > in terms of roles. If you state it in terms of roles, you will be > > > unable to > > > infer it in terms of relations. > > > > > > So, given something like: > > > > > > Process p > > > Instrument i > > > SpecificRole r > > > domain(utilizes_instrument Process) > > > range(utilizes_instrument Instrument) > > > > > > p has_participant i > > > p realizes r > > > i bears r > > > > > > We can not infer: > > > > > > p utilizes_instrument i > > > > > > Is this intended behavior? > > > > It is suboptimal, but not devastating. We still get the benefit of the > > concise statement using the relationship, and a set of inferences for > > things that we would have to state over and over again if we didn't > > use the relationship. We have to be a bit more careful if we want to > > recover all cases of the relationship in the query. However, even if > > so, we are still ahead of the game, as we would have had to do the > > harder query anyways if we didn't have the specific relation. I have > > to think about whether we can recover some of what we want using gcis, > > or new features of OWL 1.1 - that may be possible. > > > > >> I thought we had put in something to that effect, but on inspection > > >> of the file it seems we only have some documentation, and probably > > >> not adequate docs. > > >> > > >> Hopefully that explains the motivation and the difference. > > > > > > It explains it perfectly. Could I sugest that what we really require > > > is the > > > ability to use a different term ("has participant" vs "utilizes > > > instrument") > > > for a single relation (has_participant) depending on what it is > > > relating, > > > rather than a sub-relation? > > explain? > > > I understand that support for situational > > > terminology is just as absent from OWL as reasoning over properties. > > > However, > > > the rout traveled so far seems to be a terminological one represented > > > directly in the relations with unfortunate side-effects in the > > > reasoning. > > > > > >> > > >> -Alan > > > > > > Matthew > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Obi-devel mailing list > > Obi...@li... > > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > > > -- > Frank Gibson > Research Associate > Room 2.19, Devonshire Building > School of Computing Science, > University of Newcastle upon Tyne, > Newcastle upon Tyne, NE1 7RU > United Kingdom > Telephone: +44-191-246-4933 > Fax: +44-191-246-4905 > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > > -- Thanks, Allyson :) Allyson Lister Research Associate Centre for Integrated Systems Biology for Ageing and Nutrition Newcastle University http://www.cisban.ac.uk School of Computing Science Newcastle University Newcastle upon Tyne, NE1 7RU |
From: frank g. <Fra...@nc...> - 2007-12-04 10:12:48
|
Hi Alan On Nov 30, 2007 1:01 AM, Alan Ruttenberg <ala...@gm...> wrote: > Just because an instrument participates in a process doesn't mean it > is realizing the instrument's role. Then would this not require "utilizes_instrument" to be an additional relation to has_participant rather than a sub-class? some form of role_realisation relation maybe? > > So I may have a scanner, which is an instrument, but it participates > only in that I use it as a table. > One would use utilizes_instrument when the scanner is scanning > something in the process. > The utilizes_instrument (should) have the additional implications > that the domain is a process that realizes the instrument's role, and > that range (the purported instrument) has some instrument role. > > I thought we had put in something to that effect, but on inspection > of the file it seems we only have some documentation, and probably > not adequate docs. > > Hopefully that explains the motivation and the difference. I am still not clear on the difference, sorry. All I can see is that you have created a special relation which combines the role Frank > > > -Alan > > On Nov 29, 2007, at 5:01 PM, Matthew Pocock wrote: > > > Hi, > > > > I have no personal issue with utilizes_instrument vs > > utilizes_reagent vs > > has_participant. However, OWL may. If we have something like: > > > > has_participant myInstrument > > instanceOf(myInstrument Instrument) > > range(utilizes_instrument Instrument) > > > > then OWL reasoners will be unable to infer > > > > utilizes_instrument myInstrument > > > > regardless of any domain and range constraints you add. This is > > because in > > OWL, you can not state disjointness and covering constraints between > > sub-relations, only between classes. That is, you can't tell OWL > > that every > > filler has_participant that is an Instrument must be a filler of > > utlilizes_instrument, because OWL will assume that either > > has_participant > > directly, or some other sub-relation could have been intended. > > > > If you require this inference to be made, then this is a problem. > > If you > > require people to always describe participation in the most > > specific terms > > possible, then you will be OK. > > > > So, is it intended that every time you have a has_participant > > Instrument, that > > you also utilizes_instrument? > > > > Matthew > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > -- Frank Gibson Research Associate Room 2.19, Devonshire Building School of Computing Science, University of Newcastle upon Tyne, Newcastle upon Tyne, NE1 7RU United Kingdom Telephone: +44-191-246-4933 Fax: +44-191-246-4905 |
From: Alan R. <ala...@gm...> - 2007-11-30 14:55:45
Attachments:
utilizes.owl
|
On Nov 30, 2007, at 9:05 AM, frank gibson wrote: > Hi, > > I still don't see how this is more efficient than having the > has_participant relation with an instrument performing a role/ > function. What does utilises_instrument give you other than a human > readable relation conflating the role and the relation? (with-ontology utilizes () ((class !role :partial) (class !reagent_role :partial !role) (class !process :partial) (class !independent_continuant :partial) (object-property !has_role (domain !independent_continuant) (range !role)) (object-property !realization_of (domain !process) (range !role)) (object-property !has_role (domain !independent_continuant) (range !role)) (object-property !utilizes_reagent (domain (restriction !realization_of (some-values-from ! reagent_role))) (range (restriction !has_role (some-values-from !reagent_role)))) (individual !protein1 (type !protein)) (individual !process1 (type !process) (value ! utilizes_reagent !protein1))) (print (instances (restriction !has_role (some-values-from ! reagent_role)))) (print (instances (restriction !realization_of (some-values- from !reagent_role)))) (values)) => (!<http://example.com/protein1>) (!<http://example.com/process1>) i.e. it gives us that protein1 has a reagent role, and that process1 is the realization of a reagent_role, without having to state either explicitly. Efficient = say less, infer more. Ontology attached. -Alan |
From: Matthew P. <mat...@nc...> - 2007-11-30 15:17:21
|
> > On Nov 30, 2007, at 9:05 AM, frank gibson wrote: >> Hi, >> >> I still don't see how this is more efficient than having the >> has_participant relation with an instrument performing a role/ >> function. What does utilises_instrument give you other than a human >> readable relation conflating the role and the relation? > > > => > > (!<http://example.com/protein1>) > (!<http://example.com/process1>) > > i.e. it gives us that protein1 has a reagent role, and that process1 > is the realization of a reagent_role, without having to state either > explicitly. > > Efficient = say less, infer more. Ontology attached. > > -Alan Thanks for this. I agree you write less. However, you infer less, not more. You have used the specific property utilizes_reagent to infer the more general has_participant. My point is that you can't do the inverse, assert from the roles being right and the has_participant that utlizies_reagent holds. I'm replying to your earlier post more fully. Matthew |
From: Allyson L. <a.l...@ne...> - 2007-11-30 15:01:18
|
Sorry - I'm more than a little confused on the whole role/relation/property terminology. We have OBI Roles (Classes), yet there also seems to be the ability to use roles as a synonym for relations/properties? Just to clarify, is that OWL terminology? I'm getting a headache, though I think it's only because I am not knowledgeable enough about all of the different ways to name things (instances/individuals, relations/properties, etc). Thanks in advance! :) On 11/30/07, Alan Ruttenberg <ala...@gm...> wrote: > > > On Nov 30, 2007, at 9:05 AM, frank gibson wrote: > > Hi, > > > > I still don't see how this is more efficient than having the > > has_participant relation with an instrument performing a role/ > > function. What does utilises_instrument give you other than a human > > readable relation conflating the role and the relation? > > (with-ontology utilizes () > ((class !role :partial) > (class !reagent_role :partial !role) > (class !process :partial) > (class !independent_continuant :partial) > (object-property !has_role (domain !independent_continuant) > (range !role)) > (object-property !realization_of (domain !process) (range > !role)) > (object-property !has_role (domain !independent_continuant) > (range !role)) > (object-property !utilizes_reagent > (domain (restriction !realization_of (some-values-from ! > reagent_role))) > (range (restriction !has_role (some-values-from > !reagent_role)))) > (individual !protein1 (type !protein)) > (individual !process1 (type !process) (value ! > utilizes_reagent !protein1))) > (print > (instances (restriction !has_role (some-values-from ! > reagent_role)))) > (print > (instances (restriction !realization_of (some-values- > from !reagent_role)))) > (values)) > > => > > (!<http://example.com/protein1>) > (!<http://example.com/process1>) > > i.e. it gives us that protein1 has a reagent role, and that process1 > is the realization of a reagent_role, without having to state either > explicitly. > > Efficient = say less, infer more. Ontology attached. > > -Alan > > > > > > > > On Nov 30, 2007 9:28 AM, Alan Ruttenberg <ala...@gm...> > > wrote: > > > > On Nov 30, 2007, at 3:23 AM, Matthew Pocock wrote: > > > > > On Friday 30 November 2007, Alan Ruttenberg wrote: > > >> Just because an instrument participates in a process doesn't > > mean it > > >> is realizing the instrument's role. > > > > > > I quite agree - consider a scales being used to weigh a lazer. > > > > > >> So I may have a scanner, which is an instrument, but it > > participates > > >> only in that I use it as a table. > > >> One would use utilizes_instrument when the scanner is scanning > > >> something in the process. > > > > > > OK, this is clear. However, I don't think it has the entailments you > > > intend... > > > > You mean the current version in the svn?(agreed) Or the idea in > > general?(not sure what you mean) > > > > >> The utilizes_instrument (should) have the additional implications > > >> that the domain is a process that realizes the instrument's > > role, and > > >> that range (the purported instrument) has some instrument role. > > > > > > Well, clearly this is so. However, I don't think this changes the > > > inference > > > issue, and in addition, now you are stating the knowledge twice. > > > Firstly, you > > > have the role and its realization as they pertain to the instrument > > > and the > > > process. Secondly, you have a specialised relation. > > Yes, but by using the relation, with appropriate domain, range and > > possibly other axioms, we can get the other part for free. > > > Either one is sufficient > > > to know what is participating in the activity in what capacity. > > > However, > > > there is an a-symmetry here. If you state it in terms of the > > > relation, you > > > will be able to infer (given the domain/range restrictions you > > > envisage) it > > > in terms of roles. If you state it in terms of roles, you will be > > > unable to > > > infer it in terms of relations. > > > > > > So, given something like: > > > > > > Process p > > > Instrument i > > > SpecificRole r > > > domain(utilizes_instrument Process) > > > range(utilizes_instrument Instrument) > > > > > > p has_participant i > > > p realizes r > > > i bears r > > > > > > We can not infer: > > > > > > p utilizes_instrument i > > > > > > Is this intended behavior? > > > > It is suboptimal, but not devastating. We still get the benefit of the > > concise statement using the relationship, and a set of inferences for > > things that we would have to state over and over again if we didn't > > use the relationship. We have to be a bit more careful if we want to > > recover all cases of the relationship in the query. However, even if > > so, we are still ahead of the game, as we would have had to do the > > harder query anyways if we didn't have the specific relation. I have > > to think about whether we can recover some of what we want using gcis, > > or new features of OWL 1.1 - that may be possible. > > > > >> I thought we had put in something to that effect, but on inspection > > >> of the file it seems we only have some documentation, and probably > > >> not adequate docs. > > >> > > >> Hopefully that explains the motivation and the difference. > > > > > > It explains it perfectly. Could I sugest that what we really require > > > is the > > > ability to use a different term ("has participant" vs "utilizes > > > instrument") > > > for a single relation (has_participant) depending on what it is > > > relating, > > > rather than a sub-relation? > > explain? > > > I understand that support for situational > > > terminology is just as absent from OWL as reasoning over properties. > > > However, > > > the rout traveled so far seems to be a terminological one > > represented > > > directly in the relations with unfortunate side-effects in the > > > reasoning. > > > > > >> > > >> -Alan > > > > > > Matthew > > > > > > ---------------------------------------------------------------------- > > --- > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Obi-devel mailing list > > Obi...@li... > > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > > > > > -- > > Frank Gibson > > Research Associate > > Room 2.19, Devonshire Building > > School of Computing Science, > > University of Newcastle upon Tyne, > > Newcastle upon Tyne, NE1 7RU > > United Kingdom > > Telephone: +44-191-246-4933 > > Fax: +44-191-246-4905 > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > -- Thanks, Allyson :) Allyson Lister Research Associate Centre for Integrated Systems Biology for Ageing and Nutrition Newcastle University http://www.cisban.ac.uk School of Computing Science Newcastle University Newcastle upon Tyne, NE1 7RU |
From: Fostel, J. (NIH/N. [C] <fo...@ni...> - 2007-11-30 15:08:30
|
our current definition for role is this: A role is a set of connected behaviors, rights and obligations defined by an investigation or study (based in part of Wikipedia) i comes from the discussion at the last workshop, and i;ve been waiting to re-work it. i think we should add language to destinguish from function and relations. possibly a good candidate for a discussion at the face-to-face. Bill is pushing this also, but has not been available for discussions recently ________________________________ From: Allyson Lister [mailto:a.l...@ne...]=20 Sent: Friday, November 30, 2007 10:01 AM To: Alan Ruttenberg Cc: OBI Relations Mailing List; Obi...@li...; obi...@li... Subject: Re: [Obi-devel] new terms for PLAN from data_transformation Sorry - I'm more than a little confused on the whole role/relation/property terminology. We have OBI Roles (Classes), yet there also seems to be the ability to use roles as a synonym for relations/properties? Just to clarify, is that OWL terminology? I'm getting a headache, though I think it's only because I am not knowledgeable enough about all of the different ways to name things (instances/individuals, relations/properties, etc).=20 Thanks in advance! :) On 11/30/07, Alan Ruttenberg <ala...@gm...> wrote:=20 On Nov 30, 2007, at 9:05 AM, frank gibson wrote: > Hi, > > I still don't see how this is more efficient than having the=20 > has_participant relation with an instrument performing a role/ > function. What does utilises_instrument give you other than a human > readable relation conflating the role and the relation? =09 (with-ontology utilizes ()=20 ((class !role :partial) (class !reagent_role :partial !role) (class !process :partial) (class !independent_continuant :partial) (object-property !has_role (domain !independent_continuant)=20 (range !role)) (object-property !realization_of (domain !process) (range !role)) (object-property !has_role (domain !independent_continuant) (range !role)) (object-property !utilizes_reagent=20 (domain (restriction !realization_of (some-values-from ! reagent_role))) (range (restriction !has_role (some-values-from !reagent_role)))) (individual !protein1 (type !protein))=20 (individual !process1 (type !process) (value ! utilizes_reagent !protein1))) (print (instances (restriction !has_role (some-values-from ! reagent_role)))) (print=20 (instances (restriction !realization_of (some-values- from !reagent_role)))) (values)) =09 =3D> =09 (!<http://example.com/protein1>)=20 (!<http://example.com/process1>) =09 i.e. it gives us that protein1 has a reagent role, and that process1 is the realization of a reagent_role, without having to state either=20 explicitly. =09 Efficient =3D say less, infer more. Ontology attached. =09 -Alan =09 =09 =09 =09 > > On Nov 30, 2007 9:28 AM, Alan Ruttenberg <ala...@gm... > > wrote: > > On Nov 30, 2007, at 3:23 AM, Matthew Pocock wrote: > > > On Friday 30 November 2007, Alan Ruttenberg wrote: > >> Just because an instrument participates in a process doesn't=20 > mean it > >> is realizing the instrument's role. > > > > I quite agree - consider a scales being used to weigh a lazer. > > > >> So I may have a scanner, which is an instrument, but it=20 > participates > >> only in that I use it as a table. > >> One would use utilizes_instrument when the scanner is scanning > >> something in the process. > > > > OK, this is clear. However, I don't think it has the entailments you=20 > > intend... > > You mean the current version in the svn?(agreed) Or the idea in > general?(not sure what you mean) > > >> The utilizes_instrument (should) have the additional implications=20 > >> that the domain is a process that realizes the instrument's > role, and > >> that range (the purported instrument) has some instrument role. > > > > Well, clearly this is so. However, I don't think this changes the=20 > > inference > > issue, and in addition, now you are stating the knowledge twice. > > Firstly, you > > have the role and its realization as they pertain to the instrument > > and the=20 > > process. Secondly, you have a specialised relation. > Yes, but by using the relation, with appropriate domain, range and > possibly other axioms, we can get the other part for free. > > Either one is sufficient=20 > > to know what is participating in the activity in what capacity. > > However, > > there is an a-symmetry here. If you state it in terms of the > > relation, you > > will be able to infer (given the domain/range restrictions you=20 > > envisage) it > > in terms of roles. If you state it in terms of roles, you will be > > unable to > > infer it in terms of relations. > > > > So, given something like:=20 > > > > Process p > > Instrument i > > SpecificRole r > > domain(utilizes_instrument Process) > > range(utilizes_instrument Instrument) > > > > p has_participant i=20 > > p realizes r > > i bears r > > > > We can not infer: > > > > p utilizes_instrument i > > > > Is this intended behavior? > > It is suboptimal, but not devastating. We still get the benefit of the=20 > concise statement using the relationship, and a set of inferences for > things that we would have to state over and over again if we didn't > use the relationship. We have to be a bit more careful if we want to=20 > recover all cases of the relationship in the query. However, even if > so, we are still ahead of the game, as we would have had to do the > harder query anyways if we didn't have the specific relation. I have=20 > to think about whether we can recover some of what we want using gcis, > or new features of OWL 1.1 - that may be possible. > > >> I thought we had put in something to that effect, but on inspection=20 > >> of the file it seems we only have some documentation, and probably > >> not adequate docs. > >> > >> Hopefully that explains the motivation and the difference. > >=20 > > It explains it perfectly. Could I sugest that what we really require > > is the > > ability to use a different term ("has participant" vs "utilizes > > instrument")=20 > > for a single relation (has_participant) depending on what it is > > relating, > > rather than a sub-relation? > explain? > > I understand that support for situational > > terminology is just as absent from OWL as reasoning over properties.=20 > > However, > > the rout traveled so far seems to be a terminological one > represented > > directly in the relations with unfortunate side-effects in the > > reasoning. > >=20 > >> > >> -Alan > > > > Matthew > > > ---------------------------------------------------------------------- > --- > SF.Net email is sponsored by: The Future of Linux Business White Paper=20 > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4=20 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > -- > Frank Gibson > Research Associate > Room 2.19, Devonshire Building > School of Computing Science, > University of Newcastle upon Tyne, > Newcastle upon Tyne, NE1 7RU > United Kingdom > Telephone: +44-191-246-4933 > Fax: +44-191-246-4905 =09 =09 =09 ------------------------------------------------------------------------ -=20 SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Obi-devel mailing list Obi...@li...=20 https://lists.sourceforge.net/lists/listinfo/obi-devel =09 =09 =09 --=20 Thanks, Allyson :) Allyson Lister=20 Research Associate Centre for Integrated Systems Biology for Ageing and Nutrition Newcastle University http://www.cisban.ac.uk School of Computing Science Newcastle University=20 Newcastle upon Tyne, NE1 7RU=20 |
From: Matthew P. <mat...@nc...> - 2007-11-30 15:33:00
|
> Sorry - I'm more than a little confused on the whole > role/relation/property > terminology. > > We have OBI Roles (Classes), yet there also seems to be the ability to use > roles as a synonym for relations/properties? Just to clarify, is that OWL > terminology? I'm getting a headache, though I think it's only because I am > not knowledgeable enough about all of the different ways to name things > (instances/individuals, relations/properties, etc). > > Thanks in advance! > > :) Apologies :) BFO uses roles in the sense you describe. Description logics use role to mean a mathematical 2-place relation, and instance to refer to the things. OWL uses property to mean a two-place relation from an owl individual to either another owl individual or a data value, and object to mean what DLs refer to as instances. To add insult to injury, in OWL and RDF, entity is used to mean any class, property, individual etc. while in BFO, entity is the root class. This is all history from BFO comming from one particular philosophical history, DL from the mathematical community and OWL as the mongeral child of DL and frames (which, confusingly use slot to mean the same thing as owl properties, and property to mean a slot with cardinality 1). I guess prefixing BFO things with BFO: would make the text clearer, but at the same time, harder to read. Isn't the world a great place! Matthew |
From: Matthew P. <matthew.pocock@NCL.AC.UK> - 2007-11-30 15:20:41
|
>> Well, clearly this is so. However, I don't think this changes the >> inference >> issue, and in addition, now you are stating the knowledge twice. >> Firstly, you >> have the role and its realization as they pertain to the instrument >> and the >> process. Secondly, you have a specialised relation. > Yes, but by using the relation, with appropriate domain, range and > possibly other axioms, we can get the other part for free. But my point is, you only get the inference in the one direction - from specific assertions to general knowledge, not the other way around. However, as I understand it, the intended meaning of these sub-relations are derived from the more general statements. >> So, given something like: >> >> Process p >> Instrument i >> SpecificRole r >> domain(utilizes_instrument Process) >> range(utilizes_instrument Instrument) >> >> p has_participant i >> p realizes r >> i bears r >> >> We can not infer: >> >> p utilizes_instrument i >> >> Is this intended behavior? > > It is suboptimal, but not devastating. We still get the benefit of the > concise statement using the relationship, and a set of inferences for > things that we would have to state over and over again if we didn't > use the relationship. OK - this is an argument from terseness. To my way of thinking, this is a classic case of hubris that will lead to hard-to-track bugs. We are introducing a logical construct (the sub-relation utilizes_instrument) as a short-hand for another one (the super-relation has_participant with roles filled in on the players). So, we are (ab)using the sub-relation to perform the task of a macro. I understand OWL doesn't have macros, but that doesn't let us off the hook here. We are trading writing 3 axioms instead of 1 for being able to reason over the knowledge base - a poor trade in my book, as the whole point of stating things formally is to enable computational manipulations such as reasoning. And in any case, it will be software tools that write these 3 axioms vs 1 axiom in response to a user clicking on "I used this instrument" in their favorite OBI GUI and the software will not care about the extra work required. If we can guarantee that all user queries will be performed with reference to has_participant then in practice, things will be fine. Can we make that guarantee? If we do make that guarantee, what business does this sub-relation have being user-visible (rather than developer-visible)? If we can not, then we are back to the inference issue being relevant. > We have to be a bit more careful if we want to > recover all cases of the relationship in the query. However, even if > so, we are still ahead of the game, as we would have had to do the > harder query anyways if we didn't have the specific relation. I have > to think about whether we can recover some of what we want using gcis, > or new features of OWL 1.1 - that may be possible. Perhaps ... in a process, can an individual play more than one role? Can more than one individual play the same kind of role? I'd think so - A lazer could illuminate itself, a scales could weigh itself. More than one lazer could illuminate a single sample. This means we can't rely upon cardinality constraints with the has_participant players to force a locally closed world. There's nothing else in owl 1.1 [1] that is going to throw us a bone here - the added expressivity with properties doesn't address what we would need, as it doesn't do covering axioms. >> It explains it perfectly. Could I sugest that what we really require >> is the >> ability to use a different term ("has participant" vs "utilizes >> instrument") >> for a single relation (has_participant) depending on what it is >> relating, >> rather than a sub-relation? > explain? Think of it like this. Whenever you see p has_participant o, you are justified in using a sentence like "o participated in p". Whenever you see "p has_participant o ; o has_role Instrument ; p realizes Instrument" you are justified in using a sentence like "o was utilized as an instrument in p". The logical structures and the terminological ones are not 1:1 in this case. Is that more clear? Ontology is rarely 1:1 with terminology. So, I have no issue with some terminology that says "utilizes instrument" but there are other ways to capture this either in the terminology, or in the ontology that don't reduce the expressive power of our ontology. Matthew [1] http://www.webont.org/owl/1.1/semantics.html See the axioms table, and in particular those with ObjectProperty in their names |
From: Alan R. <ala...@gm...> - 2007-11-30 16:08:32
|
More detail later, but the idea that this reduces the expressivity doesn't follow. It does mean that you should query using has_participant. So the risk you raise is that because people see utilizes_reagent, they will want to query using it, and they might therefore miss some results that are either initially expressed as has_participant + other statements, or inferred. My experience here is that there is a greater risk in people not understanding or appreciating that the 3 statements are needed, than of them querying using the wrong predicate. Partially, that's because sparql queries can be easily packaged up and reused, but making developers understand why they should bother making 3 statements instead of one is not so easy. Also, you introduce extra risk in that there are 3 times as many places where you can make a mistake. Note that there is precedent for *if* semantics versus *iff* semantics in some OWL variants, so this isn't only an issue here. Google ter Horst, and check out the Oracle OWL fragments. I was thinking about property chains as the possible key to the reverse inference, BTW. I'll think a bit more. -Alan On Nov 30, 2007, at 10:20 AM, Matthew Pocock wrote: > So, I have no issue with some terminology that says "utilizes > instrument" > but there are other ways to capture this either in the terminology, > or in > the ontology that don't reduce the expressive power of our ontology. |
From: Allyson L. <a.l...@ne...> - 2007-11-30 16:14:13
|
Hi all, To my mind, the risk that we wouldn't be able to infer something is much scarier than the fact that people may not understand the 3 statements. :) On 11/30/07, Alan Ruttenberg <ala...@gm...> wrote: > > More detail later, but the idea that this reduces the expressivity > doesn't follow. It does mean that you should query using > has_participant. > > So the risk you raise is that because people see utilizes_reagent, > they will want to query using it, and they might therefore miss some > results that are either initially expressed as has_participant + other > statements, or inferred. > > My experience here is that there is a greater risk in people not > understanding or appreciating that the 3 statements are needed, than > of them querying using the wrong predicate. Partially, that's because > sparql queries can be easily packaged up and reused, but making > developers understand why they should bother making 3 statements > instead of one is not so easy. Also, you introduce extra risk in that > there are 3 times as many places where you can make a mistake. > > Note that there is precedent for *if* semantics versus *iff* semantics > in some OWL variants, so this isn't only an issue here. Google ter > Horst, and check out the Oracle OWL fragments. > > I was thinking about property chains as the possible key to the > reverse inference, BTW. I'll think a bit more. > > -Alan > > On Nov 30, 2007, at 10:20 AM, Matthew Pocock wrote: > > > So, I have no issue with some terminology that says "utilizes > > instrument" > > but there are other ways to capture this either in the terminology, > > or in > > the ontology that don't reduce the expressive power of our ontology. > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > -- Thanks, Allyson :) Allyson Lister Research Associate Centre for Integrated Systems Biology for Ageing and Nutrition Newcastle University http://www.cisban.ac.uk School of Computing Science Newcastle University Newcastle upon Tyne, NE1 7RU |
From: Alan R. <ala...@gm...> - 2007-11-30 19:04:41
|
Yes, but if they don't understand or bother to use the three statements we also won't be able to infer something. -Alan On Nov 30, 2007, at 11:14 AM, Allyson Lister wrote: > Hi all, > > To my mind, the risk that we wouldn't be able to infer something is > much scarier than the fact that people may not understand the 3 > statements. > > :) > > On 11/30/07, Alan Ruttenberg <ala...@gm...> wrote: More > detail later, but the idea that this reduces the expressivity > doesn't follow. It does mean that you should query using > has_participant. > > So the risk you raise is that because people see utilizes_reagent, > they will want to query using it, and they might therefore miss some > results that are either initially expressed as has_participant + other > statements, or inferred. > > My experience here is that there is a greater risk in people not > understanding or appreciating that the 3 statements are needed, than > of them querying using the wrong predicate. Partially, that's because > sparql queries can be easily packaged up and reused, but making > developers understand why they should bother making 3 statements > instead of one is not so easy. Also, you introduce extra risk in that > there are 3 times as many places where you can make a mistake. > > Note that there is precedent for *if* semantics versus *iff* semantics > in some OWL variants, so this isn't only an issue here. Google ter > Horst, and check out the Oracle OWL fragments. > > I was thinking about property chains as the possible key to the > reverse inference, BTW. I'll think a bit more. > > -Alan > > On Nov 30, 2007, at 10:20 AM, Matthew Pocock wrote: > > > So, I have no issue with some terminology that says "utilizes > > instrument" > > but there are other ways to capture this either in the terminology, > > or in > > the ontology that don't reduce the expressive power of our ontology. > > > ---------------------------------------------------------------------- > --- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > -- > Thanks, > Allyson :) > > Allyson Lister > Research Associate > Centre for Integrated Systems Biology for Ageing and Nutrition > Newcastle University > http://www.cisban.ac.uk > School of Computing Science > Newcastle University > Newcastle upon Tyne, NE1 7RU |
From: frank g. <Fra...@nc...> - 2007-12-04 10:19:01
|
Hi > Allyson> > To my mind, the risk that we wouldn't be able to infer something is much > scarier than the fact that people may not understand the 3 statements. > Allyson> Absolutley. Developers should have desingn principles which ensures they know what the 3 statments mean and how to write the down consistently across the all of OBI. Frank > > > On 11/30/07, Alan Ruttenberg <ala...@gm...> wrote: > > > More detail later, but the idea that this reduces the expressivity > > doesn't follow. It does mean that you should query using > > has_participant. > > > > So the risk you raise is that because people see utilizes_reagent, > > they will want to query using it, and they might therefore miss some > > results that are either initially expressed as has_participant + other > > statements, or inferred. > > > > My experience here is that there is a greater risk in people not > > understanding or appreciating that the 3 statements are needed, than > > of them querying using the wrong predicate. Partially, that's because > > sparql queries can be easily packaged up and reused, but making > > developers understand why they should bother making 3 statements > > instead of one is not so easy. Also, you introduce extra risk in that > > there are 3 times as many places where you can make a mistake. > > > > Note that there is precedent for *if* semantics versus *iff* semantics > > in some OWL variants, so this isn't only an issue here. Google ter > > Horst, and check out the Oracle OWL fragments. > > > > I was thinking about property chains as the possible key to the > > reverse inference, BTW. I'll think a bit more. > > > > -Alan > > > > On Nov 30, 2007, at 10:20 AM, Matthew Pocock wrote: > > > > > So, I have no issue with some terminology that says "utilizes > > > instrument" > > > but there are other ways to capture this either in the terminology, > > > or in > > > the ontology that don't reduce the expressive power of our ontology. > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Obi-devel mailing list > > Obi...@li... > > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > > > -- > Thanks, > Allyson :) > > Allyson Lister > Research Associate > Centre for Integrated Systems Biology for Ageing and Nutrition > Newcastle University > http://www.cisban.ac.uk > School of Computing Science > Newcastle University > Newcastle upon Tyne, NE1 7RU > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > > -- Frank Gibson Research Associate Room 2.19, Devonshire Building School of Computing Science, University of Newcastle upon Tyne, Newcastle upon Tyne, NE1 7RU United Kingdom Telephone: +44-191-246-4933 Fax: +44-191-246-4905 |
From: Matthew P. <mat...@nc...> - 2007-11-30 17:17:48
|
> More detail later, but the idea that this reduces the expressivity > doesn't follow. It does mean that you should query using > has_participant. OK - so all queries MUST be phrased in terms of has_participant. Must vs SHOULD. > > So the risk you raise is that because people see utilizes_reagent, > they will want to query using it, and they might therefore miss some > results that are either initially expressed as has_participant + other > statements, or inferred. Exactly. So this would indicate that we MUST never allow users to query using utlizes_instrument, you agree? In which case, why is it publicly exported by the ontology? > My experience here is that there is a greater risk in people not > understanding or appreciating that the 3 statements are needed, than > of them querying using the wrong predicate. Partially, that's because > sparql queries can be easily packaged up and reused, but making > developers understand why they should bother making 3 statements > instead of one is not so easy. Also, you introduce extra risk in that > there are 3 times as many places where you can make a mistake. This is primarily a documentation issue. We document the 'schema pattern' you have to fill in. Developers follow that pattern. "Q: How do I say that an instrument is used? A: use this pattern of axioms". In practice, we will need schema patterns like this for loads of things, not just using instruments. Since sparql can be package up and re-used, then let's supply the sparql query that fetches "?p utilizes instrument ?i" and name it "utilizes_instrument". The utilizes_instrument term is in the terminology, and is defined using constructs in the ontology. > Note that there is precedent for *if* semantics versus *iff* semantics > in some OWL variants, so this isn't only an issue here. Google ter > Horst, and check out the Oracle OWL fragments. These are for specific use-cases, where completeness does not matter. If I ran a query against OBI and got back only a portion of the results I thought I was getting, I would not be happy. Engineering opportunity for bugs into our ontology, for the sake of less typing, is not a good plan. > > I was thinking about property chains as the possible key to the > reverse inference, BTW. I'll think a bit more. I don't think they help here - you can't interleave following properties with class restrictions. However, I've not used property chains in anger yet (other than to implement reasoning about time) so perhaps there is some hack. Matthew > > -Alan |
From: Alan R. <ala...@gm...> - 2007-11-30 19:04:05
|
On Nov 30, 2007, at 12:17 PM, Matthew Pocock wrote: >> More detail later, but the idea that this reduces the expressivity >> doesn't follow. It does mean that you should query using >> has_participant. > > OK - so all queries MUST be phrased in terms of has_participant. > Must vs > SHOULD. Yes, that seems reasonable. >> >> So the risk you raise is that because people see utilizes_reagent, >> they will want to query using it, and they might therefore miss some >> results that are either initially expressed as has_participant + >> other >> statements, or inferred. > > Exactly. So this would indicate that we MUST never allow users to > query > using utlizes_instrument, you agree? In which case, why is it publicly > exported by the ontology? There is no notion of public versus private in OWL. >> My experience here is that there is a greater risk in people not >> understanding or appreciating that the 3 statements are needed, than >> of them querying using the wrong predicate. Partially, that's because >> sparql queries can be easily packaged up and reused, but making >> developers understand why they should bother making 3 statements >> instead of one is not so easy. Also, you introduce extra risk in that >> there are 3 times as many places where you can make a mistake. > > This is primarily a documentation issue. We document the 'schema > pattern' > you have to fill in. Developers follow that pattern. "Q: How do I > say that > an instrument is used? A: use this pattern of axioms". In practice, we > will need schema patterns like this for loads of things, not just > using > instruments. Assuming people carefully read the documentation. I stand with my intuition from experience on this one. > Since sparql can be package up and re-used, then let's supply the > sparql > query that fetches "?p utilizes instrument ?i" and name it > "utilizes_instrument". The utilizes_instrument term is in the > terminology, > and is defined using constructs in the ontology. Maybe I'm tired, but I don't understand what you are saying here. > >> Note that there is precedent for *if* semantics versus *iff* >> semantics >> in some OWL variants, so this isn't only an issue here. Google ter >> Horst, and check out the Oracle OWL fragments. > > These are for specific use-cases, where completeness does not > matter. If I > ran a query against OBI and got back only a portion of the results I > thought I was getting, I would not be happy. You will find that this will happen nonetheless, given the scale that OBI usage will grow to, and the state of reasoning technology. Sorry. > Engineering opportunity for > bugs into our ontology, for the sake of less typing, is not a good > plan. I don't agree that this is engineering in a bug. (just because you say it is, doesn't mean it is - even if you say it many times :) It is a tradeoff, and we've each enumerated what we think are the relevant parameters are. I'm still of the opinion that utilizes_reagent is the way to go. In the bulk of cases people will use the specific relation and even if they query for it will get what they expect. For the more careful among us, and if one reads the docs, then you can use the more complicated query. I think it likely that people will omit or make mistakes in rendering the longer form, and I consider the loss resulting from to have worse consequences than the other way around. For instance, it is my expectation that some portion of people will query for has_participant only and therefore get more instruments than were actually used as such in the experiment. Regards, Alan |
From: frank g. <Fra...@nc...> - 2007-11-30 19:36:19
|
Hi > > > >> My experience here is that there is a greater risk in people not > >> understanding or appreciating that the 3 statements are needed, than > >> of them querying using the wrong predicate. Partially, that's because > >> sparql queries can be easily packaged up and reused, but making > >> developers understand why they should bother making 3 statements > >> instead of one is not so easy. Also, you introduce extra risk in that > >> there are 3 times as many places where you can make a mistake. > > > > This is primarily a documentation issue. We document the 'schema > > pattern' > > you have to fill in. Developers follow that pattern. "Q: How do I > > say that > > an instrument is used? A: use this pattern of axioms". In practice, we > > will need schema patterns like this for loads of things, not just > > using > > instruments. > > Assuming people carefully read the documentation. I stand with my > intuition from experience on this one. where are is this documentation you speak off for the users that documents the design decisions made and justifies them? :) Frank |
From: Matthew P. <mat...@nc...> - 2007-12-01 21:47:15
|
On Friday 30 November 2007, Alan Ruttenberg wrote: > > OK - so all queries MUST be phrased in terms of has_participant. > > Must vs > > SHOULD. > > Yes, that seems reasonable. > > Exactly. So this would indicate that we MUST never allow users to > > query > > using utlizes_instrument, you agree? In which case, why is it publicly > > exported by the ontology? > > There is no notion of public versus private in OWL. This isn't the point. Why are we putting something into the ontology that is visible to users, which users MUST never use? > > These are for specific use-cases, where completeness does not > > matter. If I > > ran a query against OBI and got back only a portion of the results I > > thought I was getting, I would not be happy. > > You will find that this will happen nonetheless, given the scale that > OBI usage will grow to, and the state of reasoning technology. Sorry. Well, no. Reasoners either return the correct results, or they return nothing at all because they crashed. They don't return partial results. We've been pushing between 10k and 100k individuals through pellet for ComparaGRID this week, and belive me, it never half works. > > Engineering opportunity for > > bugs into our ontology, for the sake of less typing, is not a good > > plan. > > I don't agree that this is engineering in a bug. (just because you > say it is, doesn't mean it is - even if you say it many times :) > > It is a tradeoff, and we've each enumerated what we think are the > relevant parameters are. I'm still of the opinion that > utilizes_reagent is the way to go. In the bulk of cases people will > use the specific relation and even if they query for it will get what > they expect. In every case, the user will get back some of what they expected to get, and silently not get the rest. They will not know this, no error will be raised so they will proceed with incomplete data under the eroneous assumption that they are working with all of the data. We are engineering in a situation where they are guaranteed to get back incomplete data if they query with utilizes_reagent and if anybody at all has used has_participant and the roles, rather than the specific relation. If this doesn't bother you, then fine. It scares me. And given how inter-twined DL reasoning gets, one omission in reasoning like this can lead to very big failures down-stream. > For the more careful among us, and if one reads the > docs, then you can use the more complicated query. I think it likely > that people will omit or make mistakes in rendering the longer form, > and I consider the loss resulting from to have worse consequences > than the other way around. But people should not be authoring these axioms. It is for software to author them. The terms are for people. The OWL is for machines. Matthew > Regards, > Alan |
From: Alan R. <ala...@gm...> - 2007-12-01 22:47:42
|
[still going back and forth with Matthew on the same issue. Readers who are getting tired of this, just skip] On Dec 1, 2007, at 4:46 PM, Matthew Pocock wrote: > On Friday 30 November 2007, Alan Ruttenberg wrote: > >> This isn't the point. Why are we putting something into the >> ontology that is >> visible to users, which users MUST never use? We haven't said they MUST never use it. We have said to use it to express certain things and have explained how they might lose in using it for certain queries (jury is still out whether they will, per our off line conversation) >>> These are for specific use-cases, where completeness does not >>> matter. If I >>> ran a query against OBI and got back only a portion of the results I >>> thought I was getting, I would not be happy. >> >> You will find that this will happen nonetheless, given the scale that >> OBI usage will grow to, and the state of reasoning technology. Sorry. > > Well, no. Reasoners either return the correct results, or they > return nothing > at all because they crashed. They don't return partial results. > We've been > pushing between 10k and 100k individuals through pellet for > ComparaGRID this > week, and belive me, it never half works. That is one kind of reasoner. There are other kinds of reasoners that operate differently. For instance, pellet has experimented with resource bounded inference - try to do a piece of the work for 5 seconds and if it fails then give up. Pellet, in standard mode, is sound and complete. Other reasoners (in pre-semweb technologies, at least) attempt to be sound, if not complete. Use google to find out more. >>> Engineering opportunity for bugs into our ontology, for the sake >>> of less typing, is not a good >>> plan. >> >> I don't agree that this is engineering in a bug. (just because you >> say it is, doesn't mean it is - even if you say it many times :) >> >> It is a tradeoff, and we've each enumerated what we think are the >> relevant parameters are. I'm still of the opinion that >> utilizes_reagent is the way to go. In the bulk of cases people will >> use the specific relation and even if they query for it will get what >> they expect. > > In every case, the user will get back some of what they expected to > get, and > silently not get the rest. They will not know this, no error will > be raised > so they will proceed with incomplete data under the eroneous > assumption that > they are working with all of the data. We are engineering in a > situation > where they are guaranteed to get back incomplete data if they query > with > utilizes_reagent and if anybody at all has used has_participant and > the > roles, rather than the specific relation. Look, I like sound and complete too, and I'm sympathetic to your argument. It's just that there will be tradeoffs in different places as a matter of necessity. I'm happy to debate whether this is the right place to do it, but let's not fool ourselves into thinking this sort of thing is never going to happen. > If this doesn't bother you, then fine. It scares me. And given how > inter-twined DL reasoning gets, one omission in reasoning like this > can lead > to very big failures down-stream. It bothers me, but as I've said, the possibility of errors in encoding the three triples bother me too. One has to choose between suboptimal choices :( >> For the more careful among us, and if one reads the >> docs, then you can use the more complicated query. I think it likely >> that people will omit or make mistakes in rendering the longer form, >> and I consider the loss resulting from to have worse consequences >> than the other way around. > > But people should not be authoring these axioms. It is for software > to author > them. The terms are for people. The OWL is for machines. You are not being consistent here. If it is for machines to author, there is no problem having the machine rewrite the query which involves utilizes_reagent into the 3 clause form that works all the time. Both of us expect users to write stuff, just in different places. In any case, people write the computer programs and they can make the same mistakes. -Alan |