As many of you are aware, RO has been somewhat static for a while. There have been a number of proposed extensions floating around, but nothing official. Part of the problem has been the impedance mismatch between the notion of type-level relations and the corresponding treatment in OWL. In addition, many of the original instance level relations are applicable outside biology and are more suited to an upper level ontology such as BFO.
We propose that the next version of BFO will contain a minimal set of instance level binary relations -- this set will overlap with the set of instance level relations used in the original RO. These relations will have URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn (in the obo-format version, these will be rendered as BFO:nnnnnnn).
BFO will likely include the follow relations, with the following IDs/ URIs:
BFO_0000050 part of BFO_0000051 has part BFO_0000056 participates in BFO_0000057 has participant BFO_0000062 preceded by BFO_0000063 precedes BFO_0000060 immediately preceded by BFO_0000061 immediately precedes
(and will most likely include additional ones too)
The corresponding older URIs with the prefix http://obofoundry.org/ro.owl# would be mildly deprecated (i.e. they would not be rendered obsolete, but ontologies would be encouraged to switch over). The new BFO relations are unambiguously instance-level binary relations, and the definitions and comments would reflect this. This also holds for the obo-format version of these relations (previously the plan was to have distinct type-level versions of these relations specified in obo- format, but this has been abandoned in order to make the translation between obo and owl simpler).
For example, the metadata for BFO_0000050 would be something along the lines of:
definition: "part of is a primitive reflexive, transitive relation, holding either between two processes or two continuants." example: "every cell nucleus is part of some cell"
BFO will also likely include certain relations that were in various proposed extensions to the RO, but not in the original version, including, but no limited to:
BFO_0000052 inheres in BFO_0000053 bearer of BFO_0000054 realized by BFO_0000055 realizes
The idea is that BFO includes the minimal set of relations required to define BFO classes.
The primary version is in OWL, with conversions to obo-format also being made available. It will be possible to import the relations without importing all the classes.
All other relations composed from BFO minimal relations will be in a new ontology, with the namespace RO (the OBO_REL idspace/namespace will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn (and in obo-format, RO:nnnnnnn). RO will include both generic composed relations, as well as domain-specific relations. We can make the domain specific sets available as subsets/slims. For example, RO- neuron will contain a set of relations that have previously been under discussion by the PONS task force.
Many of these relations can be treated as "macros", and expanded into more complex expressions. For example:
RO_0002100 has soma part of => has_part some (GO:cell_body and part_of some ?Y) RO_0002104 => has plasma membrane part : has_part some (GO:plasma_membrane and has_part some ?Y)
We expect to be adding more soon. We've yet to specify the exact policy and guidelines, but in general the idea is that it should be fairly easy to get your relation added provided you can specify the meaning of the relation using existing relations and OWL constructs.
The primary version is also in OWL, with conversions to obo-format also being made available.
For both bfo-relations and RO, the expectation is that domain ontologies will MIREOT in relations as required (although owl:imports is also an option). The URIs would remain stable, and follow normal OBO identifier lifecycle policy. If a definition changes, the the URI/ ID is obsoleted, and a new one is minted.
> We propose that the next version of BFO will contain a minimal set of > instance level binary relations -- this set will overlap with the set > of instance level relations used in the original RO.
Chris,
This is wonderful news. We will review this proposal and submit comments.
I was wondering if the Özgövde andl Grüninger paper from FOIS this year ("Foundational Process Relations in Bio-Ontologies") influenced the proposal? Their FOL characterization struck me as potentially very useful.
Larry --------------------------------------------------------------------------- ---
I fully support your proposal and would like to propose to include a general localization relation ("has-locus" or "has-location") as well. Such a relation would be important to represent spatial inclusion of independent continuants or occurrents within independent continuants, e.g. a stone in a gallbladder, or a mitosis process in a cell.
Best regards Stefan
2010/5/26 Larry Hunter <Larry.Hun...@ucdenver.edu>:
> On May 26, 2010, at 1:35 PM, Chris Mungall wrote:
>> We propose that the next version of BFO will contain a minimal set of >> instance level binary relations -- this set will overlap with the set >> of instance level relations used in the original RO.
> Chris,
> This is wonderful news. We will review this proposal and submit comments.
> I was wondering if the Özgövde andl Grüninger paper from FOIS this year ("Foundational Process Relations in Bio-Ontologies") influenced the proposal? Their FOL characterization struck me as potentially very useful.
> Larry > --------------------------------------------------------------------------- ---
-- Stefan SCHULZ (apl. Prof. Dr. med.) Institute of Medical Biometry and Medical Informatics University Medical Center Freiburg Stefan-Meier-Strasse 26 79104 Freiburg (Germany) [home: Eschholzstr. 70, D-79115 Freiburg] +49 (0)761 2036725, 2049089 http://purl.org/steschu [stsch...@uni-freiburg.de], Skype: stschulz
Yes, I forgot to include located_in on the list - this was in the original RO and would be in BFO too. There's been a bit of discussion about this between Barry, Alan and others.
We've been unofficially using occurs_in for the process-continuant relation, we don't have a satisfactory name for the inverse yet.
> I fully support your proposal and would like to propose to include a > general localization relation ("has-locus" or "has-location") as well. > Such a relation would be important to represent spatial inclusion of > independent continuants or occurrents within independent continuants, > e.g. a stone in a gallbladder, or a mitosis process in a cell.
> Best regards > Stefan
> 2010/5/26 Larry Hunter <Larry.Hun...@ucdenver.edu>:
>> On May 26, 2010, at 1:35 PM, Chris Mungall wrote:
>>> We propose that the next version of BFO will contain a minimal set >>> of >>> instance level binary relations -- this set will overlap with the >>> set >>> of instance level relations used in the original RO.
>> Chris,
>> This is wonderful news. We will review this proposal and submit >> comments.
>> I was wondering if the Özgövde andl Grüninger paper from FOIS this >> year ("Foundational Process Relations in Bio-Ontologies") >> influenced the proposal? Their FOL characterization struck me as >> potentially very useful.
>> Larry >> --------------------------------------------------------------------------- ---
> -- > Stefan SCHULZ (apl. Prof. Dr. med.) > Institute of Medical Biometry and Medical Informatics > University Medical Center Freiburg > Stefan-Meier-Strasse 26 79104 Freiburg (Germany) > [home: Eschholzstr. 70, D-79115 Freiburg] > +49 (0)761 2036725, 2049089 > http://purl.org/steschu > [stsch...@uni-freiburg.de], Skype: stschulz
> On May 26, 2010, at 1:35 PM, Chris Mungall wrote:
>> We propose that the next version of BFO will contain a minimal set of >> instance level binary relations -- this set will overlap with the set >> of instance level relations used in the original RO.
> Chris,
> This is wonderful news. We will review this proposal and submit > comments.
> I was wondering if the Özgövde andl Grüninger paper from FOIS this > year ("Foundational Process Relations in Bio-Ontologies") influenced > the proposal? Their FOL characterization struck me as potentially > very useful.
I haven't read this paper, but that's not to say that it didn't or couldn't influence what we're doing - the belated progress we're making is the result of numerous discussions with multiple people.
On Wed, 2010-05-26 at 12:35 -0700, Chris Mungall wrote:
Hi,
This is great news. Some remarks:
> Many of these relations can be treated as "macros", and expanded into > more complex expressions. For example: > RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some (GO:plasma_membrane and > has_part some ?Y) > An early draft is available here: > http://code.google.com/p/obo-relations/source/browse/#svn/trunk/src/ > ontology
We have been working on something similar here: http://bioonto.de/obo2owl, where we provide OWL pattern definitions for all the RO relations and a few more. Many are fairly straightforward, but some are not so easy, like integral-part-of.
The patterns you use seem to contain only one variable, ?Y, while a relation between two classes will generally contain both classes as variables (?X and ?Y). So the implementation at your link does not seem to be an implementation of the RO, but rather macros for creating complex OWL class descriptions (instead of class axioms). How would you, for example, express integral-part-of?
On Wed, May 26, 2010 at 2:35 PM, Chris Mungall <c...@berkeleybop.org> wrote:
> As many of you are aware, RO has been somewhat static for a while. There > have been a number of proposed extensions floating around, but nothing > official. Part of the problem has been the impedance mismatch between the > notion of type-level relations and the corresponding treatment in OWL. In > addition, many of the original instance level relations are applicable > outside biology and are more suited to an upper level ontology such as BFO.
> We propose that the next version of BFO will contain a minimal set of > instance level binary relations -- this set will overlap with the set of > instance level relations used in the original RO. These relations will have > URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn (in the > obo-format version, these will be rendered as BFO:nnnnnnn).
> BFO will likely include the follow relations, with the following IDs/URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too)
> The corresponding older URIs with the prefix http://obofoundry.org/ro.owl#would be mildly deprecated (i.e. they would not be rendered obsolete, but > ontologies would be encouraged to switch over). The new BFO relations are > unambiguously instance-level binary relations, and the definitions and > comments would reflect this. This also holds for the obo-format version of > these relations (previously the plan was to have distinct type-level > versions of these relations specified in obo-format, but this has been > abandoned in order to make the translation between obo and owl simpler).
> For example, the metadata for BFO_0000050 would be something along the > lines of:
> definition: "part of is a primitive reflexive, transitive relation, > holding either between two processes or two continuants." > example: "every cell nucleus is part of some cell"
> BFO will also likely include certain relations that were in various > proposed extensions to the RO, but not in the original version, including, > but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
> The idea is that BFO includes the minimal set of relations required to > define BFO classes.
> The primary version is in OWL, with conversions to obo-format also being > made available. It will be possible to import the relations without > importing all the classes.
> All other relations composed from BFO minimal relations will be in a new > ontology, with the namespace RO (the OBO_REL idspace/namespace will be > mildly deprecated). URIs will be of the form > http://purl.obolibrary.org/obo/RO_nnnnnnn (and in obo-format, RO:nnnnnnn). > RO will include both generic composed relations, as well as domain-specific > relations. We can make the domain specific sets available as subsets/slims. > For example, RO-neuron will contain a set of relations that have previously > been under discussion by the PONS task force.
> Many of these relations can be treated as "macros", and expanded into more > complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some (GO:plasma_membrane and > has_part some ?Y)
> We expect to be adding more soon. We've yet to specify the exact policy and > guidelines, but in general the idea is that it should be fairly easy to get > your relation added provided you can specify the meaning of the relation > using existing relations and OWL constructs.
> The primary version is also in OWL, with conversions to obo-format also > being made available.
> For both bfo-relations and RO, the expectation is that domain ontologies > will MIREOT in relations as required (although owl:imports is also an > option). The URIs would remain stable, and follow normal OBO identifier > lifecycle policy. If a definition changes, the the URI/ID is obsoleted, and > a new one is minted.
> -- > You received this message because you are subscribed to the Google Groups > "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to > bfo-discuss+unsubscribe@googlegroups.com<bfo-discuss%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/bfo-discuss?hl=en.
> On Wed, 2010-05-26 at 12:35 -0700, Chris Mungall wrote:
> Hi,
> This is great news. Some remarks:
>> Many of these relations can be treated as "macros", and expanded into >> more complex expressions. For example: >> RO_0002100 has soma part of >> => has_part some (GO:cell_body and part_of some ?Y) >> RO_0002104 >> => has plasma membrane part : has_part some (GO:plasma_membrane and >> has_part some ?Y)
> We have been working on something similar here: > http://bioonto.de/obo2owl, where we provide OWL pattern definitions > for all the RO relations and a few more. > Many are fairly straightforward, but some are not so easy, like > integral-part-of.
> The patterns you use seem to contain only one variable, ?Y, while a > relation between two classes will generally contain both classes as > variables (?X and ?Y). So the implementation at your link does not > seem to be an implementation of the RO, but rather macros for creating > complex OWL class descriptions (instead of class axioms). > How would you, for example, express integral-part-of?
[removed bfo-discuss, since this pertains specifically to the relations in RO]
Essentially there are two types of macros. The first type expands an annotation property used in a triple. The second type expands an expression.
An example of the first (expanding an axiom):
integral_part_of(A,B) => A subclass of part_of some B, B subclass of has_part some B
An example of the second (expanding an expression):
soma_located_in_some Y => has_part some (soma and part_of some Y)
The first requires two variables in the template, the second only one.
There's a bit more to it than that, more details to follow
> Rob.
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
> I can't open the bfo2-relations.owl file, in either Protege 4.1 > alpha or Protege 3.4.4.
Hmm, seems fine in my P4.1
> part_of is also antisymmetric, although you cannot say that in OWL.
we should have a standard annotation property to indicate this, such that it will be available in FOL translations
> Since they're instance-instance relations, you can say that part_of > and has_part are inverses.
already declared
> Finally, what about instance_of and lacks (instance-type > relations)? Will they remain in RO?
The instance_of relation corresponds to a class assertion in OWL. There's a case for retaining it in a FOL version of the ontology though.
RO will most likely contain a lacks_part relation, defined in terms of zero cardinality. This could be considered either an instance-class relation, or a syntactic macro. Note that this doesn't do justice to Werner's original treatment in x lacks_part P iff x has part exactly 0 P and a typical x has part some P. I suggest that if this is required we treat this as two relations, one which is normality-neutral, and a stronger one that has implications of abnormality. I suggest retaining the label lacks_part for the simple zero-parts case and something like 'abnormally_lacks_part' for the stronger case.
At one time there was a proposal for a 3-ary lacks relation in which the first argument was a relation. For now it seems simplest just to explicitly enumerate the different binary relations.
For the cell ontology we will be using a relation
lacks_plasma_membrane_part X => has_part some (GO:plasma_membrane and has_part 0 X)
> On Wed, May 26, 2010 at 2:35 PM, Chris Mungall <c...@berkeleybop.org> > wrote:
> As many of you are aware, RO has been somewhat static for a while. > There have been a number of proposed extensions floating around, but > nothing official. Part of the problem has been the impedance > mismatch between the notion of type-level relations and the > corresponding treatment in OWL. In addition, many of the original > instance level relations are applicable outside biology and are more > suited to an upper level ontology such as BFO.
> We propose that the next version of BFO will contain a minimal set > of instance level binary relations -- this set will overlap with the > set of instance level relations used in the original RO. These > relations will have URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn > (in the obo-format version, these will be rendered as BFO:nnnnnnn).
> BFO will likely include the follow relations, with the following IDs/ > URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too)
> The corresponding older URIs with the prefix http://obofoundry.org/ro.owl# > would be mildly deprecated (i.e. they would not be rendered > obsolete, but ontologies would be encouraged to switch over). The > new BFO relations are unambiguously instance-level binary relations, > and the definitions and comments would reflect this. This also holds > for the obo-format version of these relations (previously the plan > was to have distinct type-level versions of these relations > specified in obo-format, but this has been abandoned in order to > make the translation between obo and owl simpler).
> For example, the metadata for BFO_0000050 would be something along > the lines of:
> definition: "part of is a primitive reflexive, transitive > relation, holding either between two processes or two continuants." > example: "every cell nucleus is part of some cell"
> BFO will also likely include certain relations that were in various > proposed extensions to the RO, but not in the original version, > including, but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
> The idea is that BFO includes the minimal set of relations required > to define BFO classes.
> The primary version is in OWL, with conversions to obo-format also > being made available. It will be possible to import the relations > without importing all the classes.
> All other relations composed from BFO minimal relations will be in a > new ontology, with the namespace RO (the OBO_REL idspace/namespace > will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn > (and in obo-format, RO:nnnnnnn). RO will include both generic > composed relations, as well as domain-specific relations. We can > make the domain specific sets available as subsets/slims. For > example, RO-neuron will contain a set of relations that have > previously been under discussion by the PONS task force.
> Many of these relations can be treated as "macros", and expanded > into more complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some > (GO:plasma_membrane and has_part some ?Y)
> We expect to be adding more soon. We've yet to specify the exact > policy and guidelines, but in general the idea is that it should be > fairly easy to get your relation added provided you can specify the > meaning of the relation using existing relations and OWL constructs.
> The primary version is also in OWL, with conversions to obo-format > also being made available.
> For both bfo-relations and RO, the expectation is that domain > ontologies will MIREOT in relations as required (although > owl:imports is also an option). The URIs would remain stable, and > follow normal OBO identifier lifecycle policy. If a definition > changes, the the URI/ID is obsoleted, and a new one is minted.
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
> part_of is also antisymmetric, although you cannot say that in OWL.
> Since they're instance-instance relations, you can say that part_of > and has_part are inverses.
> Finally, what about instance_of and lacks (instance-type > relations)? Will they remain in RO?
> Bill
> On Wed, May 26, 2010 at 2:35 PM, Chris Mungall <c...@berkeleybop.org> > wrote:
> As many of you are aware, RO has been somewhat static for a while. > There have been a number of proposed extensions floating around, but > nothing official. Part of the problem has been the impedance > mismatch between the notion of type-level relations and the > corresponding treatment in OWL. In addition, many of the original > instance level relations are applicable outside biology and are more > suited to an upper level ontology such as BFO.
> We propose that the next version of BFO will contain a minimal set > of instance level binary relations -- this set will overlap with the > set of instance level relations used in the original RO. These > relations will have URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn > (in the obo-format version, these will be rendered as BFO:nnnnnnn).
> BFO will likely include the follow relations, with the following IDs/ > URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too)
> The corresponding older URIs with the prefix http://obofoundry.org/ro.owl# > would be mildly deprecated (i.e. they would not be rendered > obsolete, but ontologies would be encouraged to switch over). The > new BFO relations are unambiguously instance-level binary relations, > and the definitions and comments would reflect this. This also holds > for the obo-format version of these relations (previously the plan > was to have distinct type-level versions of these relations > specified in obo-format, but this has been abandoned in order to > make the translation between obo and owl simpler).
> For example, the metadata for BFO_0000050 would be something along > the lines of:
> definition: "part of is a primitive reflexive, transitive > relation, holding either between two processes or two continuants." > example: "every cell nucleus is part of some cell"
> BFO will also likely include certain relations that were in various > proposed extensions to the RO, but not in the original version, > including, but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
> The idea is that BFO includes the minimal set of relations required > to define BFO classes.
> The primary version is in OWL, with conversions to obo-format also > being made available. It will be possible to import the relations > without importing all the classes.
> All other relations composed from BFO minimal relations will be in a > new ontology, with the namespace RO (the OBO_REL idspace/namespace > will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn > (and in obo-format, RO:nnnnnnn). RO will include both generic > composed relations, as well as domain-specific relations. We can > make the domain specific sets available as subsets/slims. For > example, RO-neuron will contain a set of relations that have > previously been under discussion by the PONS task force.
> Many of these relations can be treated as "macros", and expanded > into more complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some > (GO:plasma_membrane and has_part some ?Y)
> We expect to be adding more soon. We've yet to specify the exact > policy and guidelines, but in general the idea is that it should be > fairly easy to get your relation added provided you can specify the > meaning of the relation using existing relations and OWL constructs.
> The primary version is also in OWL, with conversions to obo-format > also being made available.
> For both bfo-relations and RO, the expectation is that domain > ontologies will MIREOT in relations as required (although > owl:imports is also an option). The URIs would remain stable, and > follow normal OBO identifier lifecycle policy. If a definition > changes, the the URI/ID is obsoleted, and a new one is minted.
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
When I open from the url below, I get some strange fragment that has has_part as a sibling of topObjectProperty, which has only 6 subproperties, 4 of which have to do with synapses.
When I try to open the file bfo-relation.owl, I get the following error: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd
with the following stack trace:
org.semanticweb.owl.io.OWLOntologyCreationIOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd at uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:174) at uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:461) at uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:424) at org.protege.editor.owl.model.OWLModelManagerImpl.loadOntology(OWLModelManag erImpl.java:328) at org.protege.editor.owl.model.OWLModelManagerImpl.loadOntologyFromPhysicalUR I(OWLModelManagerImpl.java:390) at org.protege.editor.owl.OWLEditorKit.handleLoadFrom(OWLEditorKit.java:147) at org.protege.editor.owl.OWLEditorKit.handleLoadRequest(OWLEditorKit.java:141 ) at org.protege.editor.core.ProtegeManager.openAndSetupEditorKit(ProtegeManager .java:146) at org.protege.editor.core.ProtegeWelcomeFrame$ProtegeWelcomePanel$2.actionPer formed(ProtegeWelcomeFrame.java:113) at org.protege.editor.core.ui.util.LinkLabel.activateLink(LinkLabel.java:97) at org.protege.editor.core.ui.util.LinkLabel.access$100(LinkLabel.java:30) at org.protege.editor.core.ui.util.LinkLabel$1.mouseReleased(LinkLabel.java:63 ) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity (Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknow n Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unk nown Source) at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Un known Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatche r.dispatch(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scan Document(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at edu.unika.aifb.rdf.api.syntax.RDFParser.parse(RDFParser.java:111) at org.coode.owl.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:86) at uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:159) ... 30 more
> part_of is also antisymmetric, although you cannot say that in OWL.
>> Since they're instance-instance relations, you can say that part_of and >> has_part are inverses.
>> Finally, what about instance_of and lacks (instance-type relations)? Will >> they remain in RO?
>> Bill
>> On Wed, May 26, 2010 at 2:35 PM, Chris Mungall <c...@berkeleybop.org> >> wrote:
>> As many of you are aware, RO has been somewhat static for a while. There >> have been a number of proposed extensions floating around, but nothing >> official. Part of the problem has been the impedance mismatch between the >> notion of type-level relations and the corresponding treatment in OWL. In >> addition, many of the original instance level relations are applicable >> outside biology and are more suited to an upper level ontology such as BFO.
>> We propose that the next version of BFO will contain a minimal set of >> instance level binary relations -- this set will overlap with the set of >> instance level relations used in the original RO. These relations will have >> URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn (in the >> obo-format version, these will be rendered as BFO:nnnnnnn).
>> BFO will likely include the follow relations, with the following IDs/URIs:
>> BFO_0000050 part of >> BFO_0000051 has part >> BFO_0000056 participates in >> BFO_0000057 has participant >> BFO_0000062 preceded by >> BFO_0000063 precedes >> BFO_0000060 immediately preceded by >> BFO_0000061 immediately precedes
>> (and will most likely include additional ones too)
>> The corresponding older URIs with the prefix >> http://obofoundry.org/ro.owl# would be mildly deprecated (i.e. they would >> not be rendered obsolete, but ontologies would be encouraged to switch >> over). The new BFO relations are unambiguously instance-level binary >> relations, and the definitions and comments would reflect this. This also >> holds for the obo-format version of these relations (previously the plan was >> to have distinct type-level versions of these relations specified in >> obo-format, but this has been abandoned in order to make the translation >> between obo and owl simpler).
>> For example, the metadata for BFO_0000050 would be something along the >> lines of:
>> definition: "part of is a primitive reflexive, transitive relation, >> holding either between two processes or two continuants." >> example: "every cell nucleus is part of some cell"
>> BFO will also likely include certain relations that were in various >> proposed extensions to the RO, but not in the original version, including, >> but no limited to:
>> BFO_0000052 inheres in >> BFO_0000053 bearer of >> BFO_0000054 realized by >> BFO_0000055 realizes
>> The idea is that BFO includes the minimal set of relations required to >> define BFO classes.
>> The primary version is in OWL, with conversions to obo-format also being >> made available. It will be possible to import the relations without >> importing all the classes.
>> All other relations composed from BFO minimal relations will be in a new >> ontology, with the namespace RO (the OBO_REL idspace/namespace will be >> mildly deprecated). URIs will be of the form >> http://purl.obolibrary.org/obo/RO_nnnnnnn (and in obo-format, >> RO:nnnnnnn). RO will include both generic composed relations, as well as >> domain-specific relations. We can make the domain specific sets available as >> subsets/slims. For example, RO-neuron will contain a set of relations that >> have previously been under discussion by the PONS task force.
>> Many of these relations can be treated as "macros", and expanded into more >> complex expressions. For example:
>> RO_0002100 has soma part of >> => has_part some (GO:cell_body and part_of some ?Y) >> RO_0002104 >> => has plasma membrane part : has_part some (GO:plasma_membrane and >> has_part some ?Y)
>> We expect to be adding more soon. We've yet to specify the exact policy >> and guidelines, but in general the idea is that it should be fairly easy to >> get your relation added provided you can specify the meaning of the relation >> using existing relations and OWL constructs.
>> The primary version is also in OWL, with conversions to obo-format also >> being made available.
>> For both bfo-relations and RO, the expectation is that domain ontologies >> will MIREOT in relations as required (although owl:imports is also an >> option). The URIs would remain stable, and follow normal OBO identifier >> lifecycle policy. If a definition changes, the the URI/ID is obsoleted, and >> a new one is minted.
Bill, You need to go to the checkout tab on the code.google. page. There it will tell you to use the following line command svn checkout http://bfo.googlecode.com/svn/trunk/ bfo-read-only
this will create a folder in your directory containing owl files readable by protege.
Bill Hogan wrote: > When I open from the url below, I get some strange fragment that has > has_part as a sibling of topObjectProperty, which has only 6 > subproperties, 4 of which have to do with synapses.
> When I try to open the file bfo-relation.owl, I get the following > error: Server returned HTTP response code: 503 for URL: > http://www.w3.org/TR/html4/loose.dtd
> with the following stack trace:
> org.semanticweb.owl.io.OWLOntologyCreationIOException: Server returned > HTTP response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd > at > uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:174) > at > uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:461) > at > uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:424) > at > org.protege.editor.owl.model.OWLModelManagerImpl.loadOntology(OWLModelManag erImpl.java:328) > at > org.protege.editor.owl.model.OWLModelManagerImpl.loadOntologyFromPhysicalUR I(OWLModelManagerImpl.java:390) > at > org.protege.editor.owl.OWLEditorKit.handleLoadFrom(OWLEditorKit.java:147) > at > org.protege.editor.owl.OWLEditorKit.handleLoadRequest(OWLEditorKit.java:141 ) > at > org.protege.editor.core.ProtegeManager.openAndSetupEditorKit(ProtegeManager .java:146) > at > org.protege.editor.core.ProtegeWelcomeFrame$ProtegeWelcomePanel$2.actionPer formed(ProtegeWelcomeFrame.java:113) > at > org.protege.editor.core.ui.util.LinkLabel.activateLink(LinkLabel.java:97) > at > org.protege.editor.core.ui.util.LinkLabel.access$100(LinkLabel.java:30) > at > org.protege.editor.core.ui.util.LinkLabel$1.mouseReleased(LinkLabel.java:63 ) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Window.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown > Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > Caused by: java.io.IOException: Server returned HTTP response code: > 503 for URL: http://www.w3.org/TR/html4/loose.dtd > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity (Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknow n > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unk nown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Un known > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatche r.dispatch(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scan Document(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at javax.xml.parsers.SAXParser.parse(Unknown Source) > at edu.unika.aifb.rdf.api.syntax.RDFParser.parse(RDFParser.java:111) > at > org.coode.owl.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:86) > at > uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:159) > ... 30 more
> On Wed, May 26, 2010 at 7:17 PM, Chris Mungall <c...@berkeleybop.org > <mailto:c...@berkeleybop.org>> wrote:
> On May 26, 2010, at 3:45 PM, Bill Hogan wrote:
> I can't open the bfo2-relations.owl file, in either Protege > 4.1 alpha or Protege 3.4.4.
> part_of is also antisymmetric, although you cannot say that in > OWL.
> Since they're instance-instance relations, you can say that > part_of and has_part are inverses.
> Finally, what about instance_of and lacks (instance-type > relations)? Will they remain in RO?
> Bill
> On Wed, May 26, 2010 at 2:35 PM, Chris Mungall > <c...@berkeleybop.org <mailto:c...@berkeleybop.org>> wrote:
> As many of you are aware, RO has been somewhat static for a > while. There have been a number of proposed extensions > floating around, but nothing official. Part of the problem has > been the impedance mismatch between the notion of type-level > relations and the corresponding treatment in OWL. In addition, > many of the original instance level relations are applicable > outside biology and are more suited to an upper level ontology > such as BFO.
> We propose that the next version of BFO will contain a minimal > set of instance level binary relations -- this set will > overlap with the set of instance level relations used in the > original RO. These relations will have URIs of the form > http://purl.obolibrary.org/obo/BFO_nnnnnnn (in the obo-format > version, these will be rendered as BFO:nnnnnnn).
> BFO will likely include the follow relations, with the > following IDs/URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too)
> The corresponding older URIs with the prefix > http://obofoundry.org/ro.owl# would be mildly deprecated (i.e. > they would not be rendered obsolete, but ontologies would be > encouraged to switch over). The new BFO relations are > unambiguously instance-level binary relations, and the > definitions and comments would reflect this. This also holds > for the obo-format version of these relations (previously the > plan was to have distinct type-level versions of these > relations specified in obo-format, but this has been abandoned > in order to make the translation between obo and owl simpler).
> For example, the metadata for BFO_0000050 would be something > along the lines of:
> definition: "part of is a primitive reflexive, > transitive relation, holding either between two processes or > two continuants." > example: "every cell nucleus is part of some cell"
> BFO will also likely include certain relations that were in > various proposed extensions to the RO, but not in the original > version, including, but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
> The idea is that BFO includes the minimal set of relations > required to define BFO classes.
> The primary version is in OWL, with conversions to obo-format > also being made available. It will be possible to import the > relations without importing all the classes.
> All other relations composed from BFO minimal relations will > be in a new ontology, with the namespace RO (the OBO_REL > idspace/namespace will be mildly deprecated). URIs will be of > the form http://purl.obolibrary.org/obo/RO_nnnnnnn (and in > obo-format, RO:nnnnnnn). RO will include both generic > composed relations, as well as domain-specific relations. We > can make the domain specific sets available as subsets/slims. > For example, RO-neuron will contain a set of relations that > have previously been under discussion by the PONS task force.
> Many of these relations can be treated as "macros", and > expanded into more complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some > (GO:plasma_membrane and has_part some ?Y)
New classes discussed haven't been added yet, nor have the definitions of the relations been add, nor is the axiomatization complete - this is early work.
On Wed, May 26, 2010 at 8:52 PM, Bill Hogan <hoga...@gmail.com> wrote: > When I open from the url below, I get some strange fragment that has > has_part as a sibling of topObjectProperty, which has only 6 subproperties, > 4 of which have to do with synapses.
> When I try to open the file bfo-relation.owl, I get the following error: > Server returned HTTP response code: 503 for URL: > http://www.w3.org/TR/html4/loose.dtd
> with the following stack trace:
> org.semanticweb.owl.io.OWLOntologyCreationIOException: Server returned HTTP > response code: 503 for URL: http://www.w3.org/TR/html4/loose.dtd > at > uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:174) > at > uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:461) > at > uk.ac.manchester.cs.owl.OWLOntologyManagerImpl.loadOntology(OWLOntologyMana gerImpl.java:424) > at > org.protege.editor.owl.model.OWLModelManagerImpl.loadOntology(OWLModelManag erImpl.java:328) > at > org.protege.editor.owl.model.OWLModelManagerImpl.loadOntologyFromPhysicalUR I(OWLModelManagerImpl.java:390) > at > org.protege.editor.owl.OWLEditorKit.handleLoadFrom(OWLEditorKit.java:147) > at > org.protege.editor.owl.OWLEditorKit.handleLoadRequest(OWLEditorKit.java:141 ) > at > org.protege.editor.core.ProtegeManager.openAndSetupEditorKit(ProtegeManager .java:146) > at > org.protege.editor.core.ProtegeWelcomeFrame$ProtegeWelcomePanel$2.actionPer formed(ProtegeWelcomeFrame.java:113) > at > org.protege.editor.core.ui.util.LinkLabel.activateLink(LinkLabel.java:97) > at > org.protege.editor.core.ui.util.LinkLabel.access$100(LinkLabel.java:30) > at > org.protege.editor.core.ui.util.LinkLabel$1.mouseReleased(LinkLabel.java:63 ) > at java.awt.Component.processMouseEvent(Unknown Source) > at javax.swing.JComponent.processMouseEvent(Unknown Source) > at java.awt.Component.processEvent(Unknown Source) > at java.awt.Container.processEvent(Unknown Source) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) > at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) > at java.awt.Container.dispatchEventImpl(Unknown Source) > at java.awt.Window.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at java.awt.EventQueue.dispatchEvent(Unknown Source) > at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > at java.awt.EventDispatchThread.run(Unknown Source) > Caused by: java.io.IOException: Server returned HTTP response code: 503 for > URL: http://www.w3.org/TR/html4/loose.dtd > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity (Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknow n > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(Unk nown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(Un known > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatche r.dispatch(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scan Document(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at javax.xml.parsers.SAXParser.parse(Unknown Source) > at edu.unika.aifb.rdf.api.syntax.RDFParser.parse(RDFParser.java:111) > at org.coode.owl.rdfxml.parser.RDFXMLParser.parse(RDFXMLParser.java:86) > at > uk.ac.manchester.cs.owl.ParsableOWLOntologyFactory.loadOWLOntology(Parsable OWLOntologyFactory.java:159) > ... 30 more
> On Wed, May 26, 2010 at 7:17 PM, Chris Mungall <c...@berkeleybop.org> wrote:
>> On May 26, 2010, at 3:45 PM, Bill Hogan wrote:
>>> I can't open the bfo2-relations.owl file, in either Protege 4.1 alpha or >>> Protege 3.4.4.
>>> part_of is also antisymmetric, although you cannot say that in OWL.
>>> Since they're instance-instance relations, you can say that part_of and >>> has_part are inverses.
>>> Finally, what about instance_of and lacks (instance-type relations)? >>> Will they remain in RO?
>>> Bill
>>> On Wed, May 26, 2010 at 2:35 PM, Chris Mungall <c...@berkeleybop.org> >>> wrote:
>>> As many of you are aware, RO has been somewhat static for a while. There >>> have been a number of proposed extensions floating around, but nothing >>> official. Part of the problem has been the impedance mismatch between the >>> notion of type-level relations and the corresponding treatment in OWL. In >>> addition, many of the original instance level relations are applicable >>> outside biology and are more suited to an upper level ontology such as BFO.
>>> We propose that the next version of BFO will contain a minimal set of >>> instance level binary relations -- this set will overlap with the set of >>> instance level relations used in the original RO. These relations will have >>> URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn (in the >>> obo-format version, these will be rendered as BFO:nnnnnnn).
>>> BFO will likely include the follow relations, with the following >>> IDs/URIs:
>>> BFO_0000050 part of >>> BFO_0000051 has part >>> BFO_0000056 participates in >>> BFO_0000057 has participant >>> BFO_0000062 preceded by >>> BFO_0000063 precedes >>> BFO_0000060 immediately preceded by >>> BFO_0000061 immediately precedes
>>> (and will most likely include additional ones too)
>>> The corresponding older URIs with the prefix >>> http://obofoundry.org/ro.owl# would be mildly deprecated (i.e. they would >>> not be rendered obsolete, but ontologies would be encouraged to switch >>> over). The new BFO relations are unambiguously instance-level binary >>> relations, and the definitions and comments would reflect this. This also >>> holds for the obo-format version of these relations (previously the plan was >>> to have distinct type-level versions of these relations specified in >>> obo-format, but this has been abandoned in order to make the translation >>> between obo and owl simpler).
>>> For example, the metadata for BFO_0000050 would be something along the >>> lines of:
>>> definition: "part of is a primitive reflexive, transitive relation, >>> holding either between two processes or two continuants." >>> example: "every cell nucleus is part of some cell"
>>> BFO will also likely include certain relations that were in various >>> proposed extensions to the RO, but not in the original version, including, >>> but no limited to:
>>> BFO_0000052 inheres in >>> BFO_0000053 bearer of >>> BFO_0000054 realized by >>> BFO_0000055 realizes
>>> The idea is that BFO includes the minimal set of relations required to >>> define BFO classes.
>>> The primary version is in OWL, with conversions to obo-format also being >>> made available. It will be possible to import the relations without >>> importing all the classes.
>>> All other relations composed from BFO minimal relations will be in a new >>> ontology, with the namespace RO (the OBO_REL idspace/namespace will be >>> mildly deprecated). URIs will be of the form >>> http://purl.obolibrary.org/obo/RO_nnnnnnn (and in obo-format, RO:nnnnnnn). >>> RO will include both generic composed relations, as well as domain-specific >>> relations. We can make the domain specific sets available as subsets/slims. >>> For example, RO-neuron will contain a set of relations that have previously >>> been under discussion by the PONS task force.
>>> Many of these relations can be treated as "macros", and expanded into >>> more complex expressions. For example:
>>> RO_0002100 has soma part of >>> => has_part some (GO:cell_body and part_of some ?Y) >>> RO_0002104 >>> => has plasma membrane part : has_part some (GO:plasma_membrane and >>> has_part some ?Y)
On Wed, May 26, 2010 at 4:12 PM, Stefan Schulz <stsch...@uni-freiburg.de> wrote: > Dear Chris,
> I fully support your proposal and would like to propose to include a > general localization relation ("has-locus" or "has-location") as well. > Such a relation would be important to represent spatial inclusion of > independent continuants or occurrents within independent continuants, > e.g. a stone in a gallbladder, or a mitosis process in a cell.
We need a good definition for this. The reason I haven't yet added located in and contained in is that they confuse me. (Attached is a picture I drew for discussion some time ago.)
The issue is that first, located in was defined for two cases 1) Continuant->Region 2) Continuant->Continuant
Contained in was similarly defined, but said to relate immaterial continuants to continuants.
The second relation was defined in terms of the first. The problem is that the first isn't defined. In order to probe this question, I drew the attached diagram of a bottle (wall), bottle (interior), (bottle=bottle wall+ bottle interior), some water in the bottle, and a coin in the water, and asked around what the location and containment relations were among things.
The ensuing discussion did not yield a satisfactory conclusion. Moreover there has been a recent challenge, spearheaded by Bjoern, to say that we should not define location by resort to regions (hence regions being currently optional in my draft bfo2).
Barry points to the paper "Containment Relations in Anatomical Ontologies" by Maureen Donnelly, which I like, which presents 5 candidate relations of the sort we might use. Note, however, that they still use a region function in their definitions, and afaik, this region function is not documented, and while it might seem intuitive for simple solids, it is not, IMO, in a situation in which we can have immaterial continuants (aka sites, holes, cavities).
So, do you have a favorite definition for has-locus that works for material and immaterial continuants, which relies on intuitive (or at least workable) primitives, and does not resort to regions as its basis? Or an argument as to which of these requirements should give?
The attached bottle2.graffle.pdf shows the last state of the discussion and the proposed relations among parts. A point of mystery for me is the claim that the coin not located nor contained in the water.
> 2010/5/26 Larry Hunter <Larry.Hun...@ucdenver.edu>:
>> On May 26, 2010, at 1:35 PM, Chris Mungall wrote:
>>> We propose that the next version of BFO will contain a minimal set of >>> instance level binary relations -- this set will overlap with the set >>> of instance level relations used in the original RO.
>> Chris,
>> This is wonderful news. We will review this proposal and submit comments.
>> I was wondering if the Özgövde andl Grüninger paper from FOIS this year ("Foundational Process Relations in Bio-Ontologies") influenced the proposal? Their FOL characterization struck me as potentially very useful.
>> Larry >> --------------------------------------------------------------------------- ---
> -- > Stefan SCHULZ (apl. Prof. Dr. med.) > Institute of Medical Biometry and Medical Informatics > University Medical Center Freiburg > Stefan-Meier-Strasse 26 79104 Freiburg (Germany) > [home: Eschholzstr. 70, D-79115 Freiburg] > +49 (0)761 2036725, 2049089 > http://purl.org/steschu > [stsch...@uni-freiburg.de], Skype: stschulz
> -- > You received this message because you are subscribed to the Google Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en.
this is indeed very good news and important work to be carried out. Just some small rmearks of issues of which I presume you might already be aware:
It should be ensured that all implicite relations in BFO are made explicite (inheres_in of some kind, etc.).
On the other hand it needs to be clear that no domain specific relation (or even relation named in a highly domain-contaminated way) is included in BFO since this might compromise BFO as a general Upper Ontology. One of the more theoretical issues with using RO as BFO-relations in the past (which was done inofficial sometimes) was that RO was be definition a domain specific artefact whereas BFO is an Upper Ontology in the sense of the word as used by IEEE.
Therefore, I fully support getting these things straightend out. If there is some worh that need to be done, besides discussions on the list, I would be happy to contribute, especially since I will be on a research leave in Buffalo between Septmeber 2010 and February 2011, doing some theoretical work on relations and occurents.
> As many of you are aware, RO has been somewhat static for a while. > There have been a number of proposed extensions floating around, but > nothing official. Part of the problem has been the impedance mismatch > between the notion of type-level relations and the corresponding > treatment in OWL. In addition, many of the original instance level > relations are applicable outside biology and are more suited to an > upper level ontology such as BFO.
> We propose that the next version of BFO will contain a minimal set of > instance level binary relations -- this set will overlap with the set > of instance level relations used in the original RO. These relations > will have URIs of the form http://purl.obolibrary.org/obo/BFO_nnnnnnn > (in the obo-format version, these will be rendered as BFO:nnnnnnn).
> BFO will likely include the follow relations, with the following IDs/ > URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too)
> The corresponding older URIs with the prefix http://obofoundry.org/ro.owl# > would be mildly deprecated (i.e. they would not be rendered > obsolete, but ontologies would be encouraged to switch over). The new > BFO relations are unambiguously instance-level binary relations, and > the definitions and comments would reflect this. This also holds for > the obo-format version of these relations (previously the plan was to > have distinct type-level versions of these relations specified in obo- > format, but this has been abandoned in order to make the translation > between obo and owl simpler).
> For example, the metadata for BFO_0000050 would be something along the > lines of:
> definition: "part of is a primitive reflexive, transitive relation, > holding either between two processes or two continuants." > example: "every cell nucleus is part of some cell"
> BFO will also likely include certain relations that were in various > proposed extensions to the RO, but not in the original version, > including, but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
> The idea is that BFO includes the minimal set of relations required to > define BFO classes.
> The primary version is in OWL, with conversions to obo-format also > being made available. It will be possible to import the relations > without importing all the classes.
> All other relations composed from BFO minimal relations will be in a > new ontology, with the namespace RO (the OBO_REL idspace/namespace > will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn > (and in obo-format, RO:nnnnnnn). RO will include both generic > composed relations, as well as domain-specific relations. We can make > the domain specific sets available as subsets/slims. For example, RO- > neuron will contain a set of relations that have previously been under > discussion by the PONS task force.
> Many of these relations can be treated as "macros", and expanded into > more complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some (GO:plasma_membrane and > has_part some ?Y)
> We expect to be adding more soon. We've yet to specify the exact > policy and guidelines, but in general the idea is that it should be > fairly easy to get your relation added provided you can specify the > meaning of the relation using existing relations and OWL constructs.
> The primary version is also in OWL, with conversions to obo-format > also being made available.
> For both bfo-relations and RO, the expectation is that domain > ontologies will MIREOT in relations as required (although owl:imports > is also an option). The URIs would remain stable, and follow normal > OBO identifier lifecycle policy. If a definition changes, the the URI/ > ID is obsoleted, and a new one is minted.
Chris Mungall writes: > RO will most likely contain a lacks_part relation, defined in terms of > zero cardinality. This could be considered either an instance-class > relation, or a syntactic macro. Note that this doesn't do justice to > Werner's original treatment in x lacks_part P iff x has part exactly 0 > P and a typical x has part some P. I suggest that if this is required > we treat this as two relations, one which is normality-neutral, and a > stronger one that has implications of abnormality. I suggest retaining > the label lacks_part for the simple zero-parts case and something like > 'abnormally_lacks_part' for the stronger case.
What is the zero-parts case for?
A Manx cat lacks a tail, a battleship, and the first half of *Like a Rolling Stone*. But only one of these is present in the typical cat.
I've seen PRO using the lacks relation for the peptide chain that comes fresh off the ribosome---it lacks phosphoryl groups, it lacks a ubiquitinyl group on lysine number 57, it lacks sharks---but isn't it better to say that the peptide chain has_part only canonical amino acid residues?
Best wishes, Colin.
DISCLAIMER:
This communication (including any attachments) is intended for the use of the addressee only and may contain confidential, privileged or copyright material. It may not be relied upon or disclosed to any other person without the consent of the RSC. If you have received it in error, please contact us immediately. Any advice given by the RSC has been carefully formulated but is necessarily based on the information available, and the RSC cannot be held responsible for accuracy or completeness. In this respect, the RSC owes no duty of care and shall not be liable for any resulting damage or loss. The RSC acknowledges that a disclaimer cannot restrict liability at law for personal injury or death arising through a finding of negligence. The RSC does not warrant that its emails or attachments are Virus-free: Please rely on your own screening.
Chris Mungall wrote: > BFO will likely include the follow relations, with the following IDs/ > URIs:
> BFO_0000050 part of > BFO_0000051 has part > BFO_0000056 participates in > BFO_0000057 has participant > BFO_0000062 preceded by > BFO_0000063 precedes > BFO_0000060 immediately preceded by > BFO_0000061 immediately precedes
> (and will most likely include additional ones too
> BFO will also likely include certain relations that were in various > proposed extensions to the RO, but not in the original version, > including, but no limited to:
> BFO_0000052 inheres in > BFO_0000053 bearer of > BFO_0000054 realized by > BFO_0000055 realizes
Hello,
I am glad to see a follow-up on relations after all this time! But I still wonder why some of these labels contain a verb and others not? Is there an unofficial policy that if the label doesn't contain a verb in the present tense, that it is preceded by 'is'? Why should 'part of' be read as 'is part of' instead of for instance 'has part of'? I think such labels may make it difficult for natural language processing systems that want to exploit these labels, because it is only clear for humans what to make of them.
> The primary version is in OWL, with conversions to obo-format also > being made available. It will be possible to import the relations > without importing all the classes.
> All other relations composed from BFO minimal relations will be in a > new ontology, with the namespace RO (the OBO_REL idspace/namespace > will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn > (and in obo-format, RO:nnnnnnn). RO will include both generic > composed relations, as well as domain-specific relations. We can make > the domain specific sets available as subsets/slims. For example, RO- > neuron will contain a set of relations that have previously been under > discussion by the PONS task force.
> Many of these relations can be treated as "macros", and expanded into > more complex expressions. For example:
> RO_0002100 has soma part of > => has_part some (GO:cell_body and part_of some ?Y) > RO_0002104 > => has plasma membrane part : has_part some (GO:plasma_membrane and > has_part some ?Y)
> We expect to be adding more soon. We've yet to specify the exact > policy and guidelines, but in general the idea is that it should be > fairly easy to get your relation added provided you can specify the > meaning of the relation using existing relations and OWL constructs.
> The primary version is also in OWL, with conversions to obo-format > also being made available.
> For both bfo-relations and RO, the expectation is that domain > ontologies will MIREOT in relations as required (although owl:imports > is also an option). The URIs would remain stable, and follow normal > OBO identifier lifecycle policy. If a definition changes, the the URI/ > ID is obsoleted, and a new one is minted.
On Thu, 2010-05-27 at 10:19 +0100, Colin Batchelor wrote:
Hi,
> What is the zero-parts case for? > A Manx cat lacks a tail, a battleship, and the first half of *Like a Rolling Stone*. But only one of these is present in the typical cat. > I've seen PRO using the lacks relation for the peptide chain that comes fresh off the ribosome---it lacks phosphoryl groups, it lacks a ubiquitinyl group on lysine number 57, it lacks sharks---but isn't it better to say that the peptide chain has_part only canonical amino acid residues?
The last statement would be incorrect, assuming that has_part is transitive and amino acid residues have parts which are not themselves amino acid residues (atoms and electrons, for example).
In OWL, it is sometimes useful to infer explicitly things which are not there, mostly when they are expected to be there. You could not do this otherwise because OWL uses open world reasoning, so you have to explicitly assert things which are not there, using negation.
Btw, what is the benefit of writing "has-part exactly 0" instead of "not has-part"? Both are equivalent, and the latter seems more intuitive to me.
Alan Ruttenberg writes: > The attached bottle2.graffle.pdf shows the last state of the > discussion and the proposed relations among parts. A point of mystery > for me is the claim that the coin not located nor contained in the > water.
Since this is for scientific ontologies, we should be asking what the causal consequences of the coin being underwater are. I think what's important here is that the water has the disposition to resist the movement of the coin. Equally the coin has the disposition to leach out metal atoms into the water. But these could be handled by something like a meets or an externally_connected_to relation.
If I throw the bottle into the air at night, then from where I stand that bottle might be briefly in Cassiopeia or Ursa Major. But those positions have no causal consequences. And there is no sense in which the bottle meets Alcor or Mizar.
If we were manufacturing coins-in-bottles then I think the questions would be different.
Best wishes, Colin.
DISCLAIMER:
This communication (including any attachments) is intended for the use of the addressee only and may contain confidential, privileged or copyright material. It may not be relied upon or disclosed to any other person without the consent of the RSC. If you have received it in error, please contact us immediately. Any advice given by the RSC has been carefully formulated but is necessarily based on the information available, and the RSC cannot be held responsible for accuracy or completeness. In this respect, the RSC owes no duty of care and shall not be liable for any resulting damage or loss. The RSC acknowledges that a disclaimer cannot restrict liability at law for personal injury or death arising through a finding of negligence. The RSC does not warrant that its emails or attachments are Virus-free: Please rely on your own screening.
> On Thu, 2010-05-27 at 10:19 +0100, Colin Batchelor wrote:
> Hi,
>> What is the zero-parts case for? >> A Manx cat lacks a tail, a battleship, and the first half of *Like >> a Rolling Stone*. But only one of these is present in the typical >> cat. >> I've seen PRO using the lacks relation for the peptide chain that >> comes fresh off the ribosome---it lacks phosphoryl groups, it lacks >> a ubiquitinyl group on lysine number 57, it lacks sharks---but >> isn't it better to say that the peptide chain has_part only >> canonical amino acid residues? > The last statement would be incorrect, assuming that has_part is > transitive and amino acid residues have parts which are not themselves > amino acid residues (atoms and electrons, for example).
> In OWL, it is sometimes useful to infer explicitly things which are > not there, mostly when they are expected to be there. You could not do > this otherwise because OWL uses open world reasoning, so you have to > explicitly assert things which are not there, using negation.
In my experience, we occasionally need to use negation if we are to capture the classifications that scientists find useful. Terry has especially good examples of this for classification of cell types in the immune system.
> Btw, what is the benefit of writing "has-part exactly 0" instead of > "not has-part"? Both are equivalent, and the latter seems more > intuitive to me.
As I understand it, we can't use cardinality restrictions with transitive relations in OWL. As has_part is clearly transitive, to express cardinality we would need a non-transitive child relation for has_part - perhaps 'has_component'? In this case I think I'd prefer to use explicit negation - although I worry about the hit on reasoner efficiency that might result.
David Osumi-Sutherland, PhD Ontologist / Curator Virtual Fly Brain / FlyBase Department of Genetics University of Cambridge Downing Street Cambridge, CB2 3EH UK +44 (0)1223 333 963
On Thu, May 27, 2010 at 5:47 AM, Colin Batchelor <Batchel...@rsc.org> wrote: > Alan Ruttenberg writes:
>> The attached bottle2.graffle.pdf shows the last state of the >> discussion and the proposed relations among parts. A point of mystery >> for me is the claim that the coin not located nor contained in the >> water.
> Since this is for scientific ontologies, we should be asking what the causal consequences of the coin being underwater are. I think what's important here is that the water has the disposition to resist the movement of the coin. Equally the coin has the disposition to leach out metal atoms into the water. But these could be handled by something like a meets or an externally_connected_to relation.
> If I throw the bottle into the air at night, then from where I stand that bottle might be briefly in Cassiopeia or Ursa Major. But those positions have no causal consequences. And there is no sense in which the bottle meets Alcor or Mizar.
> If we were manufacturing coins-in-bottles then I think the questions would be different.
The coin in bottle is not unlike the stone in kidney, or the protein in nucleus. There are plenty of biological cases where this configuration is relevant.
Yours firmly on earth, Alan
> Best wishes, > Colin.
> DISCLAIMER:
> This communication (including any attachments) is intended for the use of the addressee only and may contain confidential, privileged or copyright material. It may not be relied upon or disclosed to any other person without the consent of the RSC. If you have received it in error, please contact us immediately. Any advice given by the RSC has been carefully formulated but is necessarily based on the information available, and the RSC cannot be held responsible for accuracy or completeness. In this respect, the RSC owes no duty of care and shall not be liable for any resulting damage or loss. The RSC acknowledges that a disclaimer cannot restrict liability at law for personal injury or death arising through a finding of negligence. The RSC does not warrant that its emails or attachments are Virus-free: Please rely on your own screening.
On Thu, May 27, 2010 at 5:27 AM, Ward Blondé <ward.blo...@ugent.be> wrote:
> Chris Mungall wrote: >> BFO will likely include the follow relations, with the following IDs/ >> URIs:
>> BFO_0000050 part of >> BFO_0000051 has part >> BFO_0000056 participates in >> BFO_0000057 has participant >> BFO_0000062 preceded by >> BFO_0000063 precedes >> BFO_0000060 immediately preceded by >> BFO_0000061 immediately precedes
>> (and will most likely include additional ones too
>> BFO will also likely include certain relations that were in various >> proposed extensions to the RO, but not in the original version, >> including, but no limited to:
>> BFO_0000052 inheres in >> BFO_0000053 bearer of >> BFO_0000054 realized by >> BFO_0000055 realizes
> Hello,
> I am glad to see a follow-up on relations after all this time! But I > still wonder why some of these labels contain a verb and others not? Is > there an unofficial policy that if the label doesn't contain a verb in > the present tense, that it is preceded by 'is'? Why should 'part of' > be read as 'is part of' instead of for instance 'has part of'? > I think such labels may make it difficult for natural language > processing systems that want to exploit these labels, because it is only > clear for humans what to make of them.
I agree with you Ward. Now that we have ids for relations we can have a reasonable discussion of what the labels should be, without having there be the same kind of consequences as there were before. I'm inclined to change part of to is part of, and then add, as alternative terms, "part of" and "part_of", to satisfy different constituencies. If anyone has objections to this course of action, please shout.
>> The primary version is in OWL, with conversions to obo-format also >> being made available. It will be possible to import the relations >> without importing all the classes.
>> All other relations composed from BFO minimal relations will be in a >> new ontology, with the namespace RO (the OBO_REL idspace/namespace >> will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn >> (and in obo-format, RO:nnnnnnn). RO will include both generic >> composed relations, as well as domain-specific relations. We can make >> the domain specific sets available as subsets/slims. For example, RO- >> neuron will contain a set of relations that have previously been under >> discussion by the PONS task force.
>> Many of these relations can be treated as "macros", and expanded into >> more complex expressions. For example:
>> RO_0002100 has soma part of >> => has_part some (GO:cell_body and part_of some ?Y) >> RO_0002104 >> => has plasma membrane part : has_part some (GO:plasma_membrane and >> has_part some ?Y)
>> We expect to be adding more soon. We've yet to specify the exact >> policy and guidelines, but in general the idea is that it should be >> fairly easy to get your relation added provided you can specify the >> meaning of the relation using existing relations and OWL constructs.
>> The primary version is also in OWL, with conversions to obo-format >> also being made available.
>> For both bfo-relations and RO, the expectation is that domain >> ontologies will MIREOT in relations as required (although owl:imports >> is also an option). The URIs would remain stable, and follow normal >> OBO identifier lifecycle policy. If a definition changes, the the URI/ >> ID is obsoleted, and a new one is minted.
> On Thu, May 27, 2010 at 5:27 AM, Ward Blondé <ward.blo...@ugent.be> wrote:
> > Chris Mungall wrote: > >> BFO will likely include the follow relations, with the following IDs/ > >> URIs:
> >> BFO_0000050 part of > >> BFO_0000051 has part > >> BFO_0000056 participates in > >> BFO_0000057 has participant > >> BFO_0000062 preceded by > >> BFO_0000063 precedes > >> BFO_0000060 immediately preceded by > >> BFO_0000061 immediately precedes
> >> (and will most likely include additional ones too
> >> BFO will also likely include certain relations that were in various > >> proposed extensions to the RO, but not in the original version, > >> including, but no limited to:
> >> BFO_0000052 inheres in > >> BFO_0000053 bearer of > >> BFO_0000054 realized by > >> BFO_0000055 realizes
> > Hello,
> > I am glad to see a follow-up on relations after all this time! But I > > still wonder why some of these labels contain a verb and others not? Is > > there an unofficial policy that if the label doesn't contain a verb in > > the present tense, that it is preceded by 'is'? Why should 'part of' > > be read as 'is part of' instead of for instance 'has part of'? > > I think such labels may make it difficult for natural language > > processing systems that want to exploit these labels, because it is only > > clear for humans what to make of them.
> I agree with you Ward. Now that we have ids for relations we can have > a reasonable discussion of what the labels should be, without having > there be the same kind of consequences as there were before. I'm > inclined to change part of to is part of, and then add, as alternative > terms, "part of" and "part_of", to satisfy different constituencies. > If anyone has objections to this course of action, please shout.
I'm absolutely in favor of having 'is part of' as a preferred name. It mostly certainly makes it easier for language generation, and incidently, for composing queries using manchester syntax.
> >> The primary version is in OWL, with conversions to obo-format also > >> being made available. It will be possible to import the relations > >> without importing all the classes.
> >> All other relations composed from BFO minimal relations will be in a > >> new ontology, with the namespace RO (the OBO_REL idspace/namespace > >> will be mildly deprecated). URIs will be of the form > http://purl.obolibrary.org/obo/RO_nnnnnnn > >> (and in obo-format, RO:nnnnnnn). RO will include both generic > >> composed relations, as well as domain-specific relations. We can make > >> the domain specific sets available as subsets/slims. For example, RO- > >> neuron will contain a set of relations that have previously been under > >> discussion by the PONS task force.
> >> Many of these relations can be treated as "macros", and expanded into > >> more complex expressions. For example:
> >> RO_0002100 has soma part of > >> => has_part some (GO:cell_body and part_of some ?Y) > >> RO_0002104 > >> => has plasma membrane part : has_part some (GO:plasma_membrane > and > >> has_part some ?Y)
> >> We expect to be adding more soon. We've yet to specify the exact > >> policy and guidelines, but in general the idea is that it should be > >> fairly easy to get your relation added provided you can specify the > >> meaning of the relation using existing relations and OWL constructs.
> >> The primary version is also in OWL, with conversions to obo-format > >> also being made available.
> >> For both bfo-relations and RO, the expectation is that domain > >> ontologies will MIREOT in relations as required (although owl:imports > >> is also an option). The URIs would remain stable, and follow normal > >> OBO identifier lifecycle policy. If a definition changes, the the URI/ > >> ID is obsoleted, and a new one is minted.
> -- > You received this message because you are subscribed to the Google Groups > "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to > bfo-discuss+unsubscribe@googlegroups.com<bfo-discuss%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/bfo-discuss?hl=en.
-- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com
> On 27 May 2010, at 10:45, Robert Hoehndorf wrote:
> > On Thu, 2010-05-27 at 10:19 +0100, Colin Batchelor wrote:
> > Hi,
> >> What is the zero-parts case for? > >> A Manx cat lacks a tail, a battleship, and the first half of *Like > >> a Rolling Stone*. But only one of these is present in the typical > >> cat. > >> I've seen PRO using the lacks relation for the peptide chain that > >> comes fresh off the ribosome---it lacks phosphoryl groups, it lacks > >> a ubiquitinyl group on lysine number 57, it lacks sharks---but > >> isn't it better to say that the peptide chain has_part only > >> canonical amino acid residues?
> > The last statement would be incorrect, assuming that has_part is > > transitive and amino acid residues have parts which are not themselves > > amino acid residues (atoms and electrons, for example).
> > In OWL, it is sometimes useful to infer explicitly things which are > > not there, mostly when they are expected to be there. You could not do > > this otherwise because OWL uses open world reasoning, so you have to > > explicitly assert things which are not there, using negation.
> In my experience, we occasionally need to use negation if we are to > capture the classifications that scientists find useful. Terry has > especially good examples of this for classification of cell types in > the immune system.
> > Btw, what is the benefit of writing "has-part exactly 0" instead of > > "not has-part"? Both are equivalent, and the latter seems more > > intuitive to me.
agreed, using the negated form *is* more natural.
> As I understand it, we can't use cardinality restrictions with > transitive relations in OWL. As has_part is clearly transitive, to > express cardinality we would need a non-transitive child relation for > has_part - perhaps 'has_component'? In this case I think I'd prefer > to use explicit negation - although I worry about the hit on reasoner > efficiency that might result.
I think Stefan suggested 'has grain'. I suggest - 'has granular part'.
> On Thu, May 27, 2010 at 7:32 AM, Alan Ruttenberg <alanruttenb...@gmail.com > > wrote: > On Thu, May 27, 2010 at 5:27 AM, Ward Blondé <ward.blo...@ugent.be> > wrote:
> > Chris Mungall wrote: > >> BFO will likely include the follow relations, with the following > IDs/ > >> URIs:
> >> BFO_0000050 part of > >> BFO_0000051 has part > >> BFO_0000056 participates in > >> BFO_0000057 has participant > >> BFO_0000062 preceded by > >> BFO_0000063 precedes > >> BFO_0000060 immediately preceded by > >> BFO_0000061 immediately precedes
> >> (and will most likely include additional ones too
> >> BFO will also likely include certain relations that were in various > >> proposed extensions to the RO, but not in the original version, > >> including, but no limited to:
> >> BFO_0000052 inheres in > >> BFO_0000053 bearer of > >> BFO_0000054 realized by > >> BFO_0000055 realizes
> > Hello,
> > I am glad to see a follow-up on relations after all this time! But I > > still wonder why some of these labels contain a verb and others > not? Is > > there an unofficial policy that if the label doesn't contain a > verb in > > the present tense, that it is preceded by 'is'? Why should 'part > of' > > be read as 'is part of' instead of for instance 'has part of'? > > I think such labels may make it difficult for natural language > > processing systems that want to exploit these labels, because it > is only > > clear for humans what to make of them.
> I agree with you Ward. Now that we have ids for relations we can have > a reasonable discussion of what the labels should be, without having > there be the same kind of consequences as there were before. I'm > inclined to change part of to is part of, and then add, as alternative > terms, "part of" and "part_of", to satisfy different constituencies. > If anyone has objections to this course of action, please shout.
> I'm absolutely in favor of having 'is part of' as a preferred name. > It mostly certainly makes it easier for language generation,
It does? What about pluralization?
> and incidently, for composing queries using manchester syntax.
I don't find writing an underscore any more onerous than quoting a name with spaces in it.
> >> The primary version is in OWL, with conversions to obo-format also > >> being made available. It will be possible to import the relations > >> without importing all the classes.
> >> All other relations composed from BFO minimal relations will be > in a > >> new ontology, with the namespace RO (the OBO_REL idspace/namespace > >> will be mildly deprecated). URIs will be of the form http://purl.obolibrary.org/obo/RO_nnnnnnn > >> (and in obo-format, RO:nnnnnnn). RO will include both generic > >> composed relations, as well as domain-specific relations. We can > make > >> the domain specific sets available as subsets/slims. For example, > RO- > >> neuron will contain a set of relations that have previously been > under > >> discussion by the PONS task force.
> >> Many of these relations can be treated as "macros", and expanded > into > >> more complex expressions. For example:
> >> RO_0002100 has soma part of > >> => has_part some (GO:cell_body and part_of some ?Y) > >> RO_0002104 > >> => has plasma membrane part : has_part some > (GO:plasma_membrane and > >> has_part some ?Y)
> >> We expect to be adding more soon. We've yet to specify the exact > >> policy and guidelines, but in general the idea is that it should be > >> fairly easy to get your relation added provided you can specify the > >> meaning of the relation using existing relations and OWL > constructs.
> >> The primary version is also in OWL, with conversions to obo-format > >> also being made available.
> >> For both bfo-relations and RO, the expectation is that domain > >> ontologies will MIREOT in relations as required (although > owl:imports > >> is also an option). The URIs would remain stable, and follow normal > >> OBO identifier lifecycle policy. If a definition changes, the the > URI/ > >> ID is obsoleted, and a new one is minted.
> -- > You received this message because you are subscribed to the Google > Groups "BFO Discuss" group. > To post to this group, send email to bfo-discuss@googlegroups.com. > To unsubscribe from this group, send email to bfo-discuss+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en > .
> -- > Michel Dumontier > Associate Professor of Bioinformatics > Carleton University > http://dumontierlab.com > --------------------------------------------------------------------------- ---
