- From: Leonid Ototsky <leo@mgn.ru>
- Date: Thu, 12 Oct 2006 15:38:24 +0600
- To: Joanne Luciano <jluciano@genetics.med.harvard.edu>
- CC: Xiaoshu Wang <wangxiao@musc.edu>, "'Mary Montoya'" <mhm@ncgr.org>, semantic-web@w3.org, <public-semweb-lifesci@w3.org>
Joanne and all. Many of the questions in the mailing list show that we are at a "stariting point" of "more intellectual Web" . Suppose there are some foundations which must be taken into account as well. Look at the "To keep abreast of the 21st Century" paper - http://ototsky.mgn.ru/it/21abreast.htm Best, Leonid Ototsky - http://ototsky.mgn.ru/it Вы писали 12 октября 2006 г., 13:42:57: > Xiaoshu, > You raise the issue of open vs closed world, which has been on my > mind whenever any > translation to OWL comes up. I have ahead of me some databases in > OBO that I will be > looking to convert to OWL. I intend to build constructs that enable > reasoners to tell me > new things about the data. > Having had many surprises in learning how the open world works and > how OWL works > I'm curious to know how this is handled. I have not yet taken on > the task to learn > OBO as I hope not have to. I would like to feel confident that I can > convert a file into > OWL and use it, however I can't see how an automated translator, > without some > user interaction or settings can know, for example, that a set of > subclasses must > be disjoint, for example. Is the translation primarily syntactic? > What I can't imagine is how an OBO converter would know if that is > what I meant when > we didn't even know. That's my main question. > By the way, I also agree with your suggestion in response to Mary's > question and > the criticism of BioPAX. Open world and OWL are technologies that > require a lot > of careful thinking and getting used to. It takes some very > different kind of thinking > to get it right. We didn't fully appreciate this in the early days of > BioPAX and we didn't get it right. > In fact, For the first release of Level 1 didn't make the physical > entity classes disjoint. > Which is the most common mistake beginners make when going from > closed world to open world modeling. > Now a quick plug for two papers I still think are the most > enlightening for anyone > embarking on OWL. Matthew Horridge's Progege OWL Tutorial > (http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf) and > The OWL Pizza - common errors > (http://www.co-ode.org/resources/papers/ > ekaw2004.pdf). > I just re-read that one yesterday morning. > On BioPAX we are still learning about OWL and how to best use it and > reasoning technology. > We are working to correct the errors and mistakes we know about and > further educating ourselves > to hopefully get it right in future releases. > Sincerely, > Joanne > On Oct 11, 2006, at 2:47 PM, Xiaoshu Wang wrote: >> >> --Mary, >> >> I am not familiar with OBO, but what you are suggesting is actually >> what >> should be avoided in RDF. RDF is based on open world assumption. >> But to >> have one superclass for the purpose of enforcing certain annotation >> property >> is a closed world thinking in Object Oriented world. >> >> In your case, I wonder if there is any concrete criteria that makes >> one >> resource an obo:Term but the other not? If not, why invent another >> term for >> it? And doing so will at least make the statement very odd to >> understand. >> For instance, assume there is an instance of gene class Y named x. >> Then, we >> can say, >> >> @prefix gene: <http://example.com/genes#> . >> gene:Y rdfs:subClassOf obo:Term . >> >> Then it is natural to say, >> >> _:x a gene:Y . >> >> but it would be very odd to say, >> >> _:x a obo:Term . >> >> In addition, it will incur unnecessary computation complexity for RDF >> engine. >> >> This kind of pseudo-Superclass pattern is also used. Everything in >> MGED is >> an MGED:Ontology and everything in BIO-PAX is a bio-pax:entity. But >> the main >> purpose of this super-class is to enforce certain >> AnnotationProperty or >> grouping terms. No offense to those groups, but I think the design >> is wrong >> and should be avoided. >> >> To design a superclass is different form designing certain >> properties, like >> obo:name, obo:id etc., because it is still natural to say that >> something is >> a gene but has certain name and id etc., like the following, >> >> _:x a gene:Y ; >> obo:name "Some gene" ; >> obo:id "12345" . >> >> And best of all, you shouldn't invent those properties, because each >> resource should have a URI and rdfs:label can be used for name. And >> there >> are other ontology like Dublin Core at your dispense as well. >> >> You probably wondered then, how can interoperability to be ensured >> if there >> is no way to constrain it. My take to this is to think it in long >> term. >> Overtime, a few commonly used ontology would be shared by people >> who have >> the same interest. Take economy as an analogy, controled market >> have short >> term stability but destine to collapse big time some time. But >> free market >> economy have occassional turmoil, especially at the beginning but >> is more >> robust and stable in the long run. So, don't worry about how >> others will do >> in the future. Just think about if there is any ontologies that >> can help >> you adequately describe your data. >> >> Xiaoshu >> >> >>> -----Original Message----- >>> From: semantic-web-request@w3.org >>> [mailto:semantic-web-request@w3.org] On Behalf Of Mary Montoya >>> Sent: Wednesday, October 11, 2006 1:09 AM >>> To: semantic-web@w3.org; public-semweb-lifesci@w3.org >>> Subject: using OBO in owl format to describe data >>> >>> >>> I have a question about using the OpenBiomedicalOntologies >>> such as the SequenceOntology in owl format to describe data >>> resident in my local biological database. >>> >>> It seems desirable to leverage subclass relationships of >>> terms in the hierarchy of the SequenceOntology and to have >>> all the terms there rooted in a common parent obo:Term class. >>> OBO defines certain information to be provided for all OBO >>> terms such as name, id, definition, etc. These provide >>> descriptive information of the class itself not properties of >>> members of the class. So it seems all obo:Terms would have >>> "class values" for a name, id, def, etc. I would then expect >>> to find classes in SequenceOntology that are defined as >>> subClassOf obo:Term and reflect the hierachical structure of >>> those SequenceOntology terms, for example, so:Gene as a >>> subClassOf so:Region which is a subClassOf >>> so:Located_sequence_feature which is a subClassOf obo:Term. >>> The problem is that the owl class definitions I've seen for >>> OBO terms don't also include property definitions for >>> individuals of the class. So an individual of so:Gene >>> doesn't have a property for name, id, def, etc that I can >>> provide values for from my database. There are only these >>> class description properties often defined using rdfs:label, >>> rdfs:comment or as annotation type properties. >>> My question is: How can I use these publicly available >>> ontologies to hold values for my data? They seem poised for >>> interoperability if these properties were available to >>> individuals of these classes. >>> >>> Here is one sequence ontology definition I found for gene in >>> owl format ( others I've seen look similar ) >>> >>> <owl:Class rdf:ID="SO_0000704"> >>> <rdfs:label xml:lang="en">gene</rdfs:label> >>> <rdfs:comment >>> rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A >>> locatable region of genomic sequence, corresponding to a unit >>> of inheritance, which is associated with regulatory regions, >>> transcribed regions and/or other functional sequence >>> regions</rdfs:comment> >>> <rdfs:subClassOf rdf:resource="#SO_0000001"/> </owl:Class> >>> >>> I thought something like this would be more useful: >>> >>> <owl:Class rdf:about="&so;SO_0000704"> >>> <obo:classId>SO:0000704</obo:classId> >>> <obo:className>gene</obo:className> >>> <obo:classDef> >>> "A locatable region of genomic sequence, >>> corresponding to a unit of >>> inheritance, which is associated with regulatory regions, >>> transcribed regions and/or other functional >>> sequence regions" >>> [SO:rd] >>> </obo:classDef> >>> <rdfs:subClassOf rdf:resource="&so;SO_0000001"/> >>> </owl:Class> >>> >>> with the root parent Term defined within an obo namespace as >>> <owl:Class rdf:about="&obo;Term"> >>> <obo:classId>OBO:Term</obo:classId> >>> <obo:className>term</obo:className> >>> <obo:classDef> >>> Term is a blah, blah >>> </obo:classDef> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&obo;name"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&obo;id"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&obo;def"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 0 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> </owl:Class> >>> >>> Then I could do something like this: >>> >>> <owl:Class rdf:about="&mystuff;MyGene"> >>> <rdfs:subClassOf rdf:resource="&so;SO_0000704"/> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty >>> rdf:resource="&mystuff;chromosomeNumber"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty >>> rdf:resource="&mystuff;startCoordinate"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty >>> rdf:resource="&mystuff;endCoordinate"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> <rdfs:subClassOf> >>> <owl:Restriction> >>> <owl:onProperty rdf:resource="&mystuff;sequence"/> >>> <owl:minCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:minCardinality> >>> <owl:maxCardinality >>> rdf:datatype="&xsd;nonNegativeInteger"> >>> 1 >>> </owl:maxCardinality> >>> </owl:Restriction> >>> </rdfs:subClassOf> >>> </owl:Class> >>> >>> so now I have defined a class MyGene that extends from obo to >>> sequence ontology and I can define individuals with property >>> values for the following from my database: >>> obo:name >>> obo:id >>> obo:def >>> mystuff:sequence >>> mystuff:endCoordinate >>> mystuff:startCoordinate >>> mystuff:chromosomeNumber >>> >>> It seems presumptuous to define properties for individuals ( >>> name, id, etc ) as well as class properties ( className, >>> classID, etc ) for public ontologies such as obo ontologies >>> but possibly quite useful for interoperability sake. Any >>> comments would be welcome. >>> >>> Mary Montoya >>> >>> VPIN project team >>> NCGR >>> >>> >>> >>> >>> >>> >>> >> >> >> -- С уважением, Leonid mailto:leo@mgn.ru
Received on Thursday, 12 October 2006 09:38:42 UTC