microarray-ontol-digest Wednesday, March 6 2002 Volume 01 : Number 020 ---------------------------------------------------------------------- Date: 18 Feb 2002 14:34:18 -0700 From: jason@openinformatics.com (Jason E. Stewart) Subject: [microarray-ontol] MGED ontology update - --=-=-= Hey All, So a number of us met at MGED IV to discuss ontology issues and how to interface ontologies with the MAGE object model and the MAGEstk software. I thought that some of our ideas might be useful to the GO community, and I hoped that I might be able to co-opt some of your brain power to review my own thoughts. We were able to resolve a large number of issues that had been causing us hiccups ==> primarily the joining of the MAGE model with the Ontology. In order to do this, we agreed to extend the MAGE concept of an OntologyEntry to enable more complex relationships. The original concept didn't support much, primarily it knew the Ontology to which it belonged, what its unique ID was, and then an optional term_name and definition. This enabled annotating samples with ontologies of the scale of GO, but not, it turned out using the MGED ontology. To extend our support we agreed that OntologyEntry's should support a list of Slot's, were slots can point to other OntologyEntry's *or* other objects in the object model (such as Measurement's). I'm including the UML diagram for the new model in case it helps. Cheers, jas. - --=-=-= Content-Type: image/gif Content-Disposition: attachment; filename=ontology.gif Content-Transfer-Encoding: base64 Content-Description: OntologyEntry Model R0lGODlhWwIlAfEAAO/v7wAAAP//////zCH5BAEAAAAALAAAAABbAiUBAAL+hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksvmMTqtDgbX7DY9H2wu6/I7P60V2Q+Dv5wcI8EdXuIeYqLhImNDXZmd40MdY aXkpVjgYGBjJ+YnZoDlKWmp6ipqqusra6nqI+Co7S1uL6kXJCTkJ2ihqCxxMWxIgYHyMnKy8 zNzs/AwdLT39nHtXTJ2tvc0NbX1FCWu4OQjLgN2drs793YG+Dh8vH98O9z6Pn+8dinCv/8+O GMCBBPHVe+OvoMJ1BxUlXAgRWcMMD+GNolbR25/+iPtibdP08eNGhRM9EixkLGPBkhdUpkM3 UiIzl80y0szHEs1NidhiJqu4U2ZNg/wmnfw5k6TAf+8uogQpACRUlFGb8txIFWpUpomCphQq dSTVrVVhPj1WrOlTsWO9Ri3q5yhYtm615axQV5rVr2TR8u3b0y9gsXxh+s0b7a4Zt3sDkzW8 1TDktCkJPxYc+SNcQislC0aMcak+q1nRWo4cs2dbsH89czWJkfVlwF9dX3ZcuPVhzXBBx86c e6VonLtnOzb7F7jQ4JCV4+xqVzVz3cop58ZtHLP1bIqvLQw8WSkJ386mhi2Lda36ymaPV05O vjz06KkLq56cejV75tj+83aXE1959ZVlmnDjcYRgYgP9N0aA8zTHTkAIbaLANw4maNdwGG6Y 3GjzccgehCFJuIYnjuxSIYgcMQjBhSq+qAyLYbgII0MI8VKhhTWKNwKNO75oIYX9yLiEjz/y ViKOjvjiyJELauhklNNYY2KFmUjJIZFVVCmBkVFqeQ6WYupVh5JLzjhmgmBOwWUEXjq5Zopp zrkMlWb2cyWdEMUphTi91KGnjQcGGqidfx66xZuEorWZoj/y2c+iehrK5JlgOLoopGVgWqOm gggDaqiiCnNOOboIycWoqq7aSqOsvhoMlJJK6Sk4sz65R0Ocwljrrre+9OGvRMVSj68q9ir+ rJi1WmHsnO2gqpOOyZI56J7qjFXnjstuOSa2MQ57oib2AIqht0g9KCut52K5LRX+fbcurpOc MmGTasYLELIzZUXXe6bdZ1979+y1H4H3HRxRu2wKmNZ6VV0FcIiY9UUxv9aZ51Ni86pSb1w1 qQdew/7GqxbACKPHXboyETxbxSt/1mGMzYVXXcLB4jtdy9vhtt2+2sFcc2iy1GsTfO9h1fLH P08nYkc9Qrwfy1q5XBvQNPFsNW17BivVT5ZNVZzOFA+ldXZNVwNr2moDA7VxX9dmblJlu3e2 fNV+6xzLy92WtTfUmT2xgbmSnfPAYWN99d90B97R0CVCUl7V2Tn+p+Dc1zFejcpO9UtgwaV1 nnTF+VF3XNz5tqiGTemtVTDKoOstOnJal56x04Ss4gY5kaN2ltv+lFzg7AF7pe+0etn8S4n5 Vi7XlDmacmOksxKvsvESI5/jjMUaZDrOD3ZfU6ni5p5LswyBP1P11m9IKS6jhLm+RQ5Au5i0 8ad/N0nMj13NtbXvbbvbXYpe9lLT/zDHIz3Qz2P3q5P62IfA0XgvZYIYIMeMci8Agkhhc2hR A/H3tH1xjl9X8VzrwPYY4H2uLd6SWr9ONjVIcFAHjlPd6kL2sBySrIQGu97U0NWbDzowf9mS 2t9cRrPFWe5wwVGa4i4Hn7VJcYoHbGL+Ch92MY0sDXAxo0ejhBij4WCMatczmuQml0OtEGxn ViTbzKBYMQFasFUlc0/n6IY+oAkvaM8JIhglorkzknGHQeMZdjoEnr71b4mJhM+8tHdBzrhx co2c0hP51kX5+fGPKdFcWCLGQlCesDXt0c7XBmS4fwUviWV8C54gWYoCZot3SPMd3k6INd8Z aYapoqIvoUdETjbPlUPKxPvkJKldflGYxOQDM0/SwlIZUxSE+iEQi2I+9j3wmR5KXuq4SS1s PrN4s0zhaUS4uwbq6pt+64ZLfAO+oPAyUeOsHiv5B8BsZulmcjMIPSYYmk1ykpy3tGMqo2gy H+aRXfxsm0/+LBY1ia0wPxlzYUJdF8NlCpOg64oYPnmyRSV+1FkN1U0ux0azmt3TiYw8Y1M0 OlAxfg6TI5XNHtk4Pa71jpY2JR0TV7q7N9L0pQL9I0eXY9DKCbWS+tTk4PrZs5ch1aRMDJ3c lupSQBYVjEfl4RUP+rpc0q6pgnqqCD0K0dmR0Jx6ROgq+5bRrQqxq9q61TydsCuyLrKTcv0g XTe4UIbCZiVH+uFds6BX7DkTnIrNQ2ILC1OjEuOXlK2sORRo2czirq/q3CZj5XFYJjz2UZHl qmc/61QFotZu4mTmX1cL2pLCNrS2cu1pYetO2a6WtsyqZzBxe80uteSyxRzCaLX+Vdq53ha4 GbLSOVqCKN62hLk/6Y1mKbtc6uLrKbcDhDjI8amNoagRkpBjdyu4MfN2dxzjyG5ML0GKHUh3 utqNkCl9UV4TjXe/nQgvfnFU3v8ySRKPQBQHjtspRhCQhvPFS33pcxrv6uITBOaFfv/LXv2a I8MArtT4FlvfBh8hFfJdIA8QnEykoii/HfbEhVlcvj8FuMWvdK9ku7LgHHw4CCjOlNfSIuBy gPe8n6pSezecXgoPmb3+BbF2RVwEEjOYuD/osfX41CYoWHmDOM7xDeIrhC1PS0sfhnIIQ9zl WE55x1V+MLhU+2Azh/kWa2ZzD8ScLDmH2c16BgKddQz+TD+7ObiO5TOxAo2DP/sAz8Lqs6Dj nCtEJ1rRdx50bAdLXV2ZOFFqPrGXK23p1BYa0nWg8gDX6+hwgdnP12312iLt6liPz84NKrJx O+0QLdM6Wo5usKk39cgorzrXuh52gw6xaRj8ugUyTEOqJ2Dsrszh01o4JnqnbAMmHxuvu/7C si00bUlj4dfjTTR5axCOZ59A3XhZNi7uJMD2NUHKZJhxj+gHrV2IuHzJ7mC4z5Bl9db4CZSe UaV6BG8ZTxjd0hw3u4erk4SXO+FFKjiP8Z0Te/OB4uFQ0r696S5mRdzAzw23uP3McWhT/AMB P7iRvzy/fkcZHCM/OOr6ZPH+RafcTQNHeHQHXmCGt+jhwqU5rxc+Pzbl/M47f0DQTdDyp3sY 5m4iOshFDt8tnVznP3e6paBuKvyG/U5QZom7mV5tTFgdA1s/cdNL3nMadDzuRJB5tlOl9mp3 29MsJnKZvi70uJv93kFy+sPX7o68c9ruRfo71zewpqhXvdeIT3zWu8D4JFTeTHPnMHkzL4q3 D13Hl1I85hGr+Z73ve+WtznJxRf4d19e9ltSQoYvHOTXU0DybKct6LVsetr3qfFkXzjrDyx6 C/we8vUOvvAJLlrV+ynIkQ+7tjVwdpYDe/alB370pwn1xTjf29Cf96Y0tXw2jZ/83zd//SLv 7PX+sz/15Y8W8uPP/VojYZ3GJR9FkpR/+jdzzhVeLvZdcmcPjJd+RmcJmxd+Awh4LqZkurdu 1zARDqgCGEh6+BdmzzNk5zZge5cCGshsC0SCKHCCd5c6HQh3FCZgAhcDKViCJwIg8td8VZZ0 xRWCQiZdMugCYxcHPjgDQsgGjwddFPiDCkaED9iA4yJf2Ed3CLgZANiE0bOBWDeFHFgJS1iE 5jZuWbiCARiGsYeFYCh+YjiGMsCFLWiGN1iFNaiGeNeGZ/iGcKhscjiHbriFCnSHeJiHmWCD uZOEp/eHAriHucICa+h1hQiIaBiEGdh9jBiJhxgLKGhwjbh7gieIjmj+hz43ibXHhkVnc4rI fJzYiSBAijxnBOkWCcjGgwBGDshmYZ0wffmViotYh9LWhZhYdzW2ei4IgsFYYS+YeyB4i6Fn iteAitt3a9NXjAE2jMLYX9dWi7S4gMSXi8TWerzYfx5nfMDIXy8WbL8YjJeYjdoIhczYi0OC e694Kq34gXL0Pp6XfaB4juh4hOpIhcfIhJSYjMhIh7zWcnz4jwSJF1ooiYR4j4ugGPyYiQk5 f/4YiARYcxDphwrWKKKIkBaJegVZibiYhhzZkQtJkg6ZjyI5khKJTQBJhSj5hR6Jj0hoji7J gCrZG4DXkjRpjzZ5kzLJjTqpfjCJkSaZjkD+uZMYmYdEWZRGGZQkyZSJ8pQhJ5RROXxU6W9O aZVlmJXtZ5DwppRM+ZUQGZb3V3w4mYNbWWVjyYhquZQuR5HJh5aAxpZ/OJf/53GP4IrepZc8 KEPueI1xqXz1CJhop4sTCIxIh3S4R4yDOVmCyZg0hJSf54zaBo8uiGTr9ZjrZm2ZyYIMeSq+ +IyJOWMTx5l8EG2lSZjE1l7s2Jd6iWqYOY/uiJqoiGuz6XZ7SJq2OWJtp5tkKG252Zt1R23B KYVb+JfEGYNLh5x9aJx1iZLKuZwvQIqyVlnROXmnaZ3MuTCo5Zzug53ZKZ29xZ3gaXibSZ4x KJ6f1Z3e6Zjn2Y/+fUIP1pROauKev9Ce9emJ28kQwaNBmfQd+Flqx1mChQeW6XktENMwCYow Y6RDXgSgzwOB4Fag3GIRU4VSl5RSovagMIhyXWeU0/lPhxFhEfY6rVRWaEmdrwZ3EvqhBvoS xZFUg2E0PrKej7ZRAMmiQAmiFmEx6YEeCvqjd1RFSIKivuV4OaqTO6qeg8lohBYuxieg/KCk jFWjbYY2EZQmVcqV8DmegPlO0lFY4RScUwpOWgpqAuIvFCVKbPVQWASmEjWkjIKcZMpNZnpi foM0h9QfhVMgeepTNaVVxEmnRlqk/ZOnobQ0Y5U1atRG4TOnLlqnTIqnlJFKjZEzshH+VWiU OSCJopBKqFv5TnNxMAnqQ6pUOKg0MqxVao85qLblpZ8abKzKLCnqS5LqqmbppZ56q4V6ozrI ma3aq3HZpJfGobJKoUv6qrYVpc+pqyQxpIpip/I1TrRKrdVam3NQLgAlL7waU8s6h2FpQ0CK GmmUEBYVURgVWI4qrEbqrWAIrkE1F1hkVTITUnAET7YarD7Jke/6Lwb1NjylVImaVcDipda6 KtmTlfx6VZQkSAH7pziVW8mar746obgAr07BH7/jVSSqS9eCr+/VcBt6pj5GsOu6q6Eosl9W Temqrtz6G+70rH2UsiO2Wx/7siOCpU46s3tGOP7pRoeEETH+6zwSW1AoVDrlFDvnijGM8auX crPz6bPH058UZLJJYamY9KX1OlTNZawW+7NsATWlMVFeNUgQBUPYEq005FBsZTaBdVIixbSZ qbBFBKOKhDhH5DMYOrB8VbV0G6OZukhYxUdD27WYt7aSoR9iJaID0k6CC7HNBKqB2zXoqrGm mkZwxbJ8y5hz+y22YbdUpa02xUoQkrY6Nj1cu7lO+7VoZR9NxLokMzo31Uqlm2iFkrma25Sj uLl1Gqgua1pNmWW0W7tGFU1Ee2NnSYvyCI+U+Y7q1WxCxppERmDVKHZPOayv0bfHy5Lxpm+9 MJrfGILx9oKs9725p3HPSRwvIbT+Jxq5J6tq7YiZTQa/8Wu+lzmalVm/7ap93vYooeuxxvu7 yGu+ZxJ05PhK0dhhHkaOCHybXltOIqNKEyUwhOQ5tbS0Ytq+E+t44PtdeWlrO5jA12eL4ygu 9Ki/HsC5SJFFR4RTQOs1WstUGJywsCqsqluq4kpGLRy1rruoOSunwmqwqtK0/DsUmVqpstu4 Aju4qprBIJu6REw4+nFHo3ShlsuxiqoxAKxcO7uK93MTwpttNMzFVppn6QrG6CbGYzyyZWqz AazGPJZOMIQ2RVMubbzFhZsqcXypSAuoCHLGcpfGCWvDD7zHZftCChWnJeu7d/zEDkzIJYqm ervEOkv+lderoTUMxRgFM3VzLo5bNjK7yH41xI5cUIW8sA/7yW/WxNrLpINcJ6gUVcCTppib yBGbvW78xmSsLtgbyp2Vy3AMJ7cbULfMyL+8xpGqxaJszGkZxLBix8qMx/TUpcQMzY1suNPc y148yteMrNTsy9FcbTVbsM0cKtucx9i8zOmsiqSMzOrszrkjzu8szzoRz/Nszw1Sz/esz+wc yPs8heQM0CfMQFTqz2s5AAeN0Amt0AvN0A3t0A8N0REt0RNN0Qot0JYMygXdhgFQ0R3t0R8N 0iE90RztKRityhrtriKt0ivN0i1t0QeNfvmM0lnI0S5t0zeN0w9d0wMAKSb+TckzjU05LdRD fdM7zdNsINNA3RsIXQgwTdQUbdQ4HdU8vdJRHSc+TaxK/c9OndBTzdVPHdFT7dUjzdRVvdCR l9RaHQo1bdUw/Qdu3dZvLddNvdNGrQlwXdY8TddvzdR83dQWbdd6zdZ/zdd47dBeDSZY7aBq 3Sh9XdZ1/dWOLddd7dRt7dZ5zdZcLdZfHdhUrdmY7dmQDdFjTWYBfbCM3diUTdWivdmhbdgk /dKX/dmu7dmqLdpwzdqgfdeR3dD0htq/fWCxDduzbduV/dmWrdegTdutfdu1rdyu3dog/cfA vdGGHdqFXdizTdK7LdaEjd3abdWD3d2sndnX3dz+Hj3d1J3SYM3bzs3e733Y6i3fLfHeiA3f 9x3f863fXYLf/e3f+b3fAS4Ko33e/23gVS3gCV4HBC7bB87QY+3gD67gEz4JuA3Yso3d3l3e 4p3cj73dDS7Y2x3edZ3hfv3XQp3eFK5gse3hq83b5a3dxD3XLl7bG87iMC7c7W3TKa7iDtHX cQ3buy3Yeb3cFh7jQm7jqk3bXe3XOu7SPN7jsUDclR3kOa7cSV7cNJ7lyI3jRe7eRR3lCS7e 2d3ZGj7XY87Z373caj7YgH3eo7DkOQ3lYe5YEW7n9U3nAQ7hd87nLD3neQ4gfS7oUg3o+k3i 2Q3VH33iIr3nvS3Rjf7+5b1d6PPd5h1+1oet6Dpd0ZB+6X4+0pMu3ziO5hqO2SU+3Foe4kOe 6pFd6R3O4V5O2DVu6ZF+1qCu3qIe47Ku5aee2a+O5ZAd15wd57Be3MNd4BJu68CN68R+3I+t 26wu485O2UKu61dO5L2+6rRu0cmu7Bie5DCO7cbd7M7969Ju7tJu2cuO7dGt09z+24ee267O 5qZ+7U1+3dB+6bGu2fbO3fZe4/4+2u6O2pzu6U6e6J3u3wT/5wK/GESN5CpN8IN+1Ayv1REv 8RcP4BQ/0xaP8R3f1Rqv1Bzv8R6/8CA/IyOP8p9u8igt8ikv8SW/8rjg8jMv6TFf0C1P83xP DvM2nyg57/MwzfP+jPM/7+A7H/TjRvQ5b/RHzyxJT/NLz/Tu4vQzD/VR3ydT7/JVb/VahvUp r/Vbz22mLfYiCPZlb/Znj/Zpr/ZrX/YFAAA7 - --=-=-=-- ------------------------------ Date: Mon, 18 Feb 2002 13:09:12 -0800 (PST) From: Chris Mungall Subject: Re: [microarray-ontol] MGED ontology update On 18 Feb 2002, Jason E. Stewart wrote: > Hey All, > > So a number of us met at MGED IV to discuss ontology issues and how to > interface ontologies with the MAGE object model and the MAGEstk > software. I thought that some of our ideas might be useful to the GO > community, and I hoped that I might be able to co-opt some of your > brain power to review my own thoughts. > > We were able to resolve a large number of issues that had been causing > us hiccups ==> primarily the joining of the MAGE model with the > Ontology. In order to do this, we agreed to extend the MAGE concept of > an OntologyEntry to enable more complex relationships. The original > concept didn't support much, primarily it knew the Ontology to which > it belonged, what its unique ID was, and then an optional term_name > and definition. This enabled annotating samples with ontologies of the > scale of GO, but not, it turned out using the MGED ontology. This is a tricky issue. How deep do you model using a database schema / objects, when do you decide where to make the transition into an ontology, and how do you link the two? > To extend our support we agreed that OntologyEntry's should support a > list of Slot's, were slots can point to other OntologyEntry's *or* > other objects in the object model (such as Measurement's). Some comments - * Shouldn't slot name be an ontology entry itself? * What about 'measurement's that are floats/ints? By forcing them all into a string field you limit some of the queries you can do, indexes will be less effective, etc. * The UML includes Slot-->Measurement and Slot-->OntologyEntry; you imply above that a slot can point _any_ object in the object model which is a bit worrisome. * I guess I'm not sure exactly what an OntologyEntry is. Is it for representing classes, instances, or both? /// There are a number of approaches I can think of: most generic solution: ~~~~~~~~~~~~~~~~~~~~~~ generalised graph tables (node and arc). Effectively an RDF-type database. You can then layer anything you like on top of that. You could use DAML-OIL or just take cues from how it layers a frame based system onto a graph. this is quite extreme in terms of how generic it is. the SQL queries required will probably be quite unintuitive. one advantage is that you can reuse the same structures for the metadata which could be useful. It looks like your model could be similar to this. In RDF terms OntologyEntry - Subject Slot - Predicate Measurement - Object Your is different in that the statements/arcs aren't first class entities. radical solution: ~~~~~~~~~~~~~~~~~ ditch UML and model *all* of MGED/MAGE in an ontology! a solution i don't like much: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ take a cut through your ontology, model the the upper nodes in UML in such a way that you deal with slots by treating them as traditional attributes/columns. The lower/deeper part of the ontology doesn't introduce any slot refinements and can be treated as a taxonomic controlled vocabulary a la GO. Not very generic, and likely to lead to brittle slowly evolving ontologies. But it really depends on your ontology. Plus UML/OCL just isn't that good for this sort of thing. /// I don't know much about MAGE/MGED, so some questions: * Does your ontology require lists anywhere, or are unordered sets fine? * Do you want to include meta data (eg slot constraints) in the database/object model, or will this always be external? It looks from the UML that you can't represent slot constraints, this may be fine, but there could be some value in including the meta data, to enforce integrity at the db/object layer. * Do you ever use subProperties? (could cause problems with the model you've specified, as the predicates are not OntologyEntries) I guess some use cases would help me understand this. Right now this isn't relevant to the main GO ontologies as we don't have any need of slots. However, we may need slots for our SO ontology so it's good to have this discussion now. > I'm including the UML diagram for the new model in case it helps. > > Cheers, > jas. > > ------------------------------ Date: Mon, 18 Feb 2002 14:15:42 -0800 From: "Miller, Michael (Rosetta)" Subject: RE: [microarray-ontol] MGED ontology update Hi Chris, Thanks for your comments. You are right, this is a tricky issue. >ditch UML and model *all* of MGED/MAGE in an ontology! when you have a hammer all solutions look like nails! To be more serious, one point to make about MAGE-OM is that we have attempted to capture the concepts and relationships of objects that people involved with Gene Expression Data consider key and the feedback we've gotten is that we've done a great to adequate job (depending on who you ask). >* I guess I'm not sure exactly what an OntologyEntry is. Is it for >representing classes, instances, or both? We are not including Ontologies as a whole in the model, only a way to create or reference instances from an ontology and to point, in the cases that one exists (i.e. GO), to relevant documentation by using the identifier in the ontology. Ontology entries in MAGE-OM are simply for taking care of the annotation cases where 1) There are diverse choices and there exist ontologies that can better capture the information than our model can (a biomaterial's characteristics--genotype, age, sex, etc.--is the best example) or 2) what are essentially controlled vocabularies which are limited in number of choices but might grow in the future or vary by technology type (ControlType for a feature/spot). >How deep do you model using a database schema / objects, when do you >decide where to make the transition into an ontology, and how do you link >the two? The MAGE-OM specifies first class objects for Gene Expression data interchange. An ontology entry can be used only in those places where there is an association to it. Best practice when given a choice is to use the MAGE-OM object instead of the ontology entry. >* Shouldn't slot name be an ontology entry itself? My impression from the discussion with the MGED Ontology people was that an Ontology Entry had slots that could either point to other Ontology Entries, an Enumeration or a Measurement. This is what we tried to capture. If there is a better way (perhaps slot is a subclass of OntologyEntry?) we would be open to the idea. >* What about 'measurement's that are floats/ints? By forcing them all into >a string field you limit some of the queries you can do, indexes will be >less effective, etc. The Measurement object in MAGE-OM specifies a CORBA type of 'any', which the Unit association is used to specify the type. Plus, we are not mandating any database or implementation details in MAGE-OM. >I don't know much about MAGE/MGED, so some questions: In answer to these questions, its important to remember, as above, we aren't specifying ontologies, where we thought appropriate, we are letting people use the ontologies they are currently using or will decide to use. Without over complicating one area of the model we want to allow just enough richness for people to specify an instance of an ontology for annotation purposes. What 'just enough' means is the tricky part. These are all good issues, Chris. In light of the fact that we are not trying to model ontologies, just instances, what issues do you still see? Michael Michael Miller Senior Application Developer Rosetta Biosoftware michael_miller@rosettabio.com - -----Original Message----- From: Chris Mungall [mailto:cjm@fruitfly.bdgp.berkeley.edu] Sent: Monday, February 18, 2002 1:09 PM To: Jason E. Stewart Cc: go@genome.Stanford.EDU; microarray-ontol@ebi.ac.uk Subject: Re: [microarray-ontol] MGED ontology update On 18 Feb 2002, Jason E. Stewart wrote: > Hey All, > > So a number of us met at MGED IV to discuss ontology issues and how to > interface ontologies with the MAGE object model and the MAGEstk > software. I thought that some of our ideas might be useful to the GO > community, and I hoped that I might be able to co-opt some of your > brain power to review my own thoughts. > > We were able to resolve a large number of issues that had been causing > us hiccups ==> primarily the joining of the MAGE model with the > Ontology. In order to do this, we agreed to extend the MAGE concept of > an OntologyEntry to enable more complex relationships. The original > concept didn't support much, primarily it knew the Ontology to which > it belonged, what its unique ID was, and then an optional term_name > and definition. This enabled annotating samples with ontologies of the > scale of GO, but not, it turned out using the MGED ontology. This is a tricky issue. How deep do you model using a database schema / objects, when do you decide where to make the transition into an ontology, and how do you link the two? > To extend our support we agreed that OntologyEntry's should support a > list of Slot's, were slots can point to other OntologyEntry's *or* > other objects in the object model (such as Measurement's). Some comments - * Shouldn't slot name be an ontology entry itself? * What about 'measurement's that are floats/ints? By forcing them all into a string field you limit some of the queries you can do, indexes will be less effective, etc. * The UML includes Slot-->Measurement and Slot-->OntologyEntry; you imply above that a slot can point _any_ object in the object model which is a bit worrisome. * I guess I'm not sure exactly what an OntologyEntry is. Is it for representing classes, instances, or both? /// There are a number of approaches I can think of: most generic solution: ~~~~~~~~~~~~~~~~~~~~~~ generalised graph tables (node and arc). Effectively an RDF-type database. You can then layer anything you like on top of that. You could use DAML-OIL or just take cues from how it layers a frame based system onto a graph. this is quite extreme in terms of how generic it is. the SQL queries required will probably be quite unintuitive. one advantage is that you can reuse the same structures for the metadata which could be useful. It looks like your model could be similar to this. In RDF terms OntologyEntry - Subject Slot - Predicate Measurement - Object Your is different in that the statements/arcs aren't first class entities. radical solution: ~~~~~~~~~~~~~~~~~ ditch UML and model *all* of MGED/MAGE in an ontology! a solution i don't like much: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ take a cut through your ontology, model the the upper nodes in UML in such a way that you deal with slots by treating them as traditional attributes/columns. The lower/deeper part of the ontology doesn't introduce any slot refinements and can be treated as a taxonomic controlled vocabulary a la GO. Not very generic, and likely to lead to brittle slowly evolving ontologies. But it really depends on your ontology. Plus UML/OCL just isn't that good for this sort of thing. /// I don't know much about MAGE/MGED, so some questions: * Does your ontology require lists anywhere, or are unordered sets fine? * Do you want to include meta data (eg slot constraints) in the database/object model, or will this always be external? It looks from the UML that you can't represent slot constraints, this may be fine, but there could be some value in including the meta data, to enforce integrity at the db/object layer. * Do you ever use subProperties? (could cause problems with the model you've specified, as the predicates are not OntologyEntries) I guess some use cases would help me understand this. Right now this isn't relevant to the main GO ontologies as we don't have any need of slots. However, we may need slots for our SO ontology so it's good to have this discussion now. > I'm including the UML diagram for the new model in case it helps. > > Cheers, > jas. > > ------------------------------ Date: 18 Feb 2002 17:14:04 -0700 From: jason@openinformatics.com (Jason E. Stewart) Subject: Re: [microarray-ontol] MGED ontology update "Chris Mungall" writes: > This is a tricky issue. Hey Chris, Thanks for taking a poke at this. > How deep do you model using a database schema / objects, when do you > decide where to make the transition into an ontology, and how do you > link the two? Yeah, that's what we're slowly coming to grips with. Luckily, I think that both efforts still have sufficient flexibility to handle changes. The line that we have drawn is roughly: * components that are highly variable will be described by objects from the model. Examples: protocols, measurements, contact information, data matrices. * components that are non-variable will be describe by the Ontology. Examples: units, channel names, data type names, types of biolocical materials (RNA, DNA, etc.) * components necessary for making comparisons will be put in ontologies: are samples derived from the same strain, do experimental designs test the same condition * components necessary for standardized annotations will be put in the ontology. * any thing else is described by objects from the model. > > To extend our support we agreed that OntologyEntry's should support a > > list of Slot's, were slots can point to other OntologyEntry's *or* > > other objects in the object model (such as Measurement's). > > Some comments - > > * Shouldn't slot name be an ontology entry itself? Possibly, but not the way we were modelling it. It is part of an ontology entry, not a separate entity. There are 37 places in MAGE that refer to OntologyEntries - basically any field that was likely to be queried where we originally thought to use a free text string. Of them 36 are likely to be implemented by simple controlled vocabulary lists, or simple hierarchical ontologies like GO. The only one that isn't is the BioSample:characteristics, which is the focus of the MGED Ontology effort so far. These are all the characteristics that define a biological sample, things like: strain, cell-type, tissue-type, age, phenotype, genotype, species, etc. I had hoped to keep my life simple and make the category names one Ontology, and then the values for each category be separate ontologies. That way, each characteristic would have two entries: one for the name, one for the value. This route wasn't chosen. > * What about 'measurement's that are floats/ints? By forcing them all into > a string field you limit some of the queries you can do, indexes will be > less effective, etc. Correct, in the real model it's actually of type 'Any', I just simplified it to String in my cut down version, sorry. > * The UML includes Slot-->Measurement and Slot-->OntologyEntry; you imply > above that a slot can point _any_ object in the object model which is a > bit worrisome. Not *any* object - currently only a Measurement or another OntologyEntry. We're trying to pin down if there are any other objects that it might need to point to. > * I guess I'm not sure exactly what an OntologyEntry is. Is it for > representing classes, instances, or both? Not instances. We're still working to avoid those. I was hoping that I'll we'd need to model is the unique identifier, but there were some examples that broke this: * sample age: 7 days after planting This is a sample characteristic: age, and it clearly this includes a measurement (7 days), so what to do? > There are a number of approaches I can think of: > > most generic solution: > ~~~~~~~~~~~~~~~~~~~~~~ that's probably too far for MAGE-1.0 to handle > radical solution: > ~~~~~~~~~~~~~~~~~ > > ditch UML and model *all* of MGED/MAGE in an ontology! That's what Chris (Stoeckert) was doing, but we can't. The OMG want's CORBA or UML, so we gave them UML. > a solution i don't like much: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > take a cut through your ontology, model the the upper nodes in UML in such > a way that you deal with slots by treating them as traditional > attributes/columns. The lower/deeper part of the ontology doesn't > introduce any slot refinements and can be treated as a taxonomic > controlled vocabulary a la GO. > > Not very generic, and likely to lead to brittle slowly evolving > ontologies. But it really depends on your ontology. Not sure if I grok what you're getting at with this, sorry. > Plus UML/OCL just isn't that good for this sort of thing. Not sure I know what OCL is. > I don't know much about MAGE/MGED, so some questions: > > * Does your ontology require lists anywhere, or are unordered sets > fine? As far as I know, ordered lists are not being used, yet. > * Do you want to include meta data (eg slot constraints) in the > database/object model, or will this always be external? It looks > from the UML that you can't represent slot constraints, this may be > fine, but there could be some value in including the meta data, to > enforce integrity at the db/object layer. I don't want to store the entire Ontology in MAGE, I just need to be able to reference the individual entries that which are annotating the data. > * Do you ever use subProperties? (could cause problems with the model > you've specified, as the predicates are not OntologyEntries) Don't know. > I guess some use cases would help me understand this. You and me both. I'll spend some time collecting dificult ones. > Right now this isn't relevant to the main GO ontologies as we don't have > any need of slots. However, we may need slots for our SO ontology so it's > good to have this discussion now. Yes, that's why I thought it might be useful. What are the issues that made you consider using slots for SO? Thanks, jas. ------------------------------ Date: Mon, 18 Feb 2002 14:38:31 -0800 From: "Miller, Michael (Rosetta)" Subject: RE: [microarray-ontol] MGED ontology update Jason, A lot of your answers are much more specific than mine, thanks for the clarity. The one place we differed significantly is: >> * I guess I'm not sure exactly what an OntologyEntry is. Is it for >> representing classes, instances, or both? > Not instances. We're still working to avoid those. I consider an ontology entry an instance if its used in a context, such as we are doing when creating a MAGE XML document. But I think, in general, we are on the same page, that is, if many sequences refer to the same GO entry, that is not a separate entry, I would consider it the same instance. a much lesser point: >> radical solution: >> ~~~~~~~~~~~~~~~~~ >> >> ditch UML and model *all* of MGED/MAGE in an ontology! > > That's what Chris (Stoeckert) was doing, but we can't. The OMG want's > CORBA or UML, so we gave them UML. In truth, for me, UML is a very handy tool/view of a system if it's to be implemented as software. The parts of UML we used probably do fit nicely into an ontology model, since MAGE is a data model. But if one wanted to start adding services or workflow (just as an example, not that I think we need to) then I think the UML is more useful representation. thanks, Michael ------------------------------ Date: Mon, 18 Feb 2002 17:12:33 -0800 (PST) From: Chris Mungall Subject: Re: [microarray-ontol] MGED ontology update On 18 Feb 2002, Jason E. Stewart wrote: > > How deep do you model using a database schema / objects, when do you > > decide where to make the transition into an ontology, and how do you > > link the two? > > Yeah, that's what we're slowly coming to grips with. Luckily, I think > that both efforts still have sufficient flexibility to handle > changes. > > The line that we have drawn is roughly: > > * components that are highly variable will be described by objects > from the model. Examples: protocols, measurements, contact > information, data matrices. > > * components that are non-variable will be describe by the > Ontology. Examples: units, channel names, data type names, types of > biolocical materials (RNA, DNA, etc.) > > * components necessary for making comparisons will be put in > ontologies: are samples derived from the same strain, do > experimental designs test the same condition > > * components necessary for standardized annotations will be put in the > ontology. > > * any thing else is described by objects from the model. Sounds sensible > > > To extend our support we agreed that OntologyEntry's should support a > > > list of Slot's, were slots can point to other OntologyEntry's *or* > > > other objects in the object model (such as Measurement's). > > > > Some comments - > > > > * Shouldn't slot name be an ontology entry itself? > > Possibly, but not the way we were modelling it. It is part of an > ontology entry, not a separate entity. > > There are 37 places in MAGE that refer to OntologyEntries - basically > any field that was likely to be queried where we originally thought to > use a free text string. Of them 36 are likely to be implemented by > simple controlled vocabulary lists, or simple hierarchical ontologies > like GO. > > The only one that isn't is the BioSample:characteristics, which is the > focus of the MGED Ontology effort so far. These are all the > characteristics that define a biological sample, things like: strain, > cell-type, tissue-type, age, phenotype, genotype, species, etc. > > I had hoped to keep my life simple and make the category names one > Ontology, and then the values for each category be separate > ontologies. That way, each characteristic would have two entries: one > for the name, one for the value. > > This route wasn't chosen. > > > * What about 'measurement's that are floats/ints? By forcing them all into > > a string field you limit some of the queries you can do, indexes will be > > less effective, etc. > > Correct, in the real model it's actually of type 'Any', I just > simplified it to String in my cut down version, sorry. Ok > > * The UML includes Slot-->Measurement and Slot-->OntologyEntry; you imply > > above that a slot can point _any_ object in the object model which is a > > bit worrisome. > > Not *any* object - currently only a Measurement or another > OntologyEntry. We're trying to pin down if there are any other objects > that it might need to point to. Ah, ok. > > * I guess I'm not sure exactly what an OntologyEntry is. Is it for > > representing classes, instances, or both? > > Not instances. We're still working to avoid those. > > I was hoping that I'll we'd need to model is the unique identifier, > but there were some examples that broke this: > > * sample age: 7 days after planting > > This is a sample characteristic: age, and it clearly this includes a > measurement (7 days), so what to do? I can see a number of ways to represent this statement using the UML model you gave, not 100% sure which you have in mind. It might help to have a formal or semi-formal way of representing how to turn instances of the ontology classes into instances of UML classes. (I'm not clear as to whether the UML you provide is intended to be capable of representing any instances of any ontology, or is less general and is only intended to solve a certain number of use cases for the biomaterials ontology) I think what is necessary to avoid getting into a nasty pickle is a well defined mapping between the two, like this: [DAML+OIL on the left, pseudo java-UML on the right] (?I daml:type ?Class) ---> ?I instanceOf OntologyEntry, ?I.name == ?Class. (?Property daml:type daml:Property), (?I ?Property ?Value) --> ?I.slot instanceOf Slot, ?I.slot.name == ?Property, ?I.slot.measurementValue instanceOf Measurement, ?I.slot.measurementValue.value == ?Value, ?I.slot.measurementValue.unit instanceOf OntologyEntry The above is recursive (ie Value can be an OntologyEntry) which allows for more complex statements, although Properties cannot be ontology entries. It needs some modification for representing primitives, and for mutliple slots, and slots with cardinailty>1 but I hope someone gets the basic idea. Perhaps the mapping is something you're already comfortable with and don't feel the need to state explicitly, but I think something semi-formal like the above would be very useful for seeing exactly what it is possible to represent in the UML model and how. There may be a standard way of doing this kind of mapping, I'm not sure. > > There are a number of approaches I can think of: > > > > most generic solution: > > ~~~~~~~~~~~~~~~~~~~~~~ > > that's probably too far for MAGE-1.0 to handle > > > radical solution: > > ~~~~~~~~~~~~~~~~~ > > > > ditch UML and model *all* of MGED/MAGE in an ontology! > > That's what Chris (Stoeckert) was doing, but we can't. The OMG want's > CORBA or UML, so we gave them UML. Oh, this is for an OMG submission I have a vague recollection that the biological sequence analysis submission included XML as part of the spec. So I guess in theory you could have an XML-RDF blob string as your ontology entry. Admittedly it's kind of opaque. > > a solution i don't like much: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > take a cut through your ontology, model the the upper nodes in UML in such > > a way that you deal with slots by treating them as traditional > > attributes/columns. The lower/deeper part of the ontology doesn't > > introduce any slot refinements and can be treated as a taxonomic > > controlled vocabulary a la GO. > > > > Not very generic, and likely to lead to brittle slowly evolving > > ontologies. But it really depends on your ontology. > > Not sure if I grok what you're getting at with this, sorry. For example, you would have actual UML classes for Age, Species, Tissue, Strain etc and a controlled vocabulary for units, a controlled vocabulary for species, tissue-types etc. > > Plus UML/OCL just isn't that good for this sort of thing. > > Not sure I know what OCL is. Object Constraint Language http://www-3.ibm.com/software/ad/library/standards/ocl.html Basically it extends UML, allows constraints which help make a more rigorous, less ambiguous model, like you would have in a full fledged ontology. > > * Do you want to include meta data (eg slot constraints) in the > > database/object model, or will this always be external? It looks > > from the UML that you can't represent slot constraints, this may be > > fine, but there could be some value in including the meta data, to > > enforce integrity at the db/object layer. > > I don't want to store the entire Ontology in MAGE, I just need to be > able to reference the individual entries that which are annotating the > data. Where does the constraint that prevents someone entering, say, "sample:age 12 transcription-factors" or other such nonsense? I guess the object model itself doesn't care, and this is passed on to the application, which may (or may not) choose to use the ontology to validate? > > * Do you ever use subProperties? (could cause problems with the model > > you've specified, as the predicates are not OntologyEntries) > > Don't know. > > > I guess some use cases would help me understand this. > > You and me both. I'll spend some time collecting dificult ones. Ok, be interested to see them. > > Right now this isn't relevant to the main GO ontologies as we don't have > > any need of slots. However, we may need slots for our SO ontology so it's > > good to have this discussion now. > > Yes, that's why I thought it might be useful. What are the issues that > made you consider using slots for SO? I may be on my own on this one, but I think slots will be necessary for fully capturing everything with the ontology. For instance, a variable-region class will want a slot for the allele/phenotype class to go. > Thanks, > jas. > - -- chris ------------------------------ Date: Tue, 19 Feb 2002 21:19:44 +0000 From: Ugis Sarkans Subject: Re: [microarray-ontol] MGED ontology update This is a multi-part message in MIME format. - --------------040803060708000001010007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael, Chris, Jason, At MGED I said that I would like to see a metamodel of ontologies before deciding how to solve MAGE+ontologies issues. I am attaching a simple class diagram that is supposed to represent a subset of OIL metamodel, just the features used in the current MGED ontology for sample descriptions. In general the idea of adding "Slot" class to MAGE seems to be right, just some points about terminology. On the Individuals level there are Instances and Relations, "Slot" is a Class level concept, so probably in MAGE what we thought would be "Slot" class should be called e.g. OntologyRelation. Actually now I think OntologyEntry is not a good term, it is really not clear whether we want to model entire ontologies or something else. What about something else, like OntologyInstance or OntologyInstanceReference? Miller, Michael (Rosetta) wrote: >>> radical solution: >>> ~~~~~~~~~~~~~~~~~ >>> >>> ditch UML and model *all* of MGED/MAGE in an ontology! >> >> That's what Chris (Stoeckert) was doing, but we can't. The OMG want's >> CORBA or UML, so we gave them UML. > > In truth, for me, UML is a very handy tool/view of a system if it's to be > implemented as software. The parts of UML we used probably do fit nicely > into an ontology model, since MAGE is a data model. But if one wanted to > start adding services or workflow (just as an example, not that I think we > need to) then I think the UML is more useful representation. Another point is that UML offers a standard diagrammatic (2-D) way of representing models, and this is important for complex models where there are many relations between classes. For ontologies representation is (structured) text, which is a 1-D thing. But probably there is some work on how to visualize ontologies? Regards, Ugis - -- ============================================================ Ugis Sarkans Tel:+44-(0)1223 494603 European Bioinformatics Institute Fax:+44-(0)1223 494468 Hinxton, Cambridge CB10 1SD UK Email:ugis@ebi.ac.uk ============================================================ - --------------040803060708000001010007 Content-Type: image/png; name="oil.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="oil.png" iVBORw0KGgoAAAANSUhEUgAAAzgAAAJBBAMAAAB4+A0MAAAAMFBMVEUAAACcADH//wD//87/ //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABWGqx2AAAWI0lEQVR42u2dC3ak oBKGOcEFXG9YQGZWwD1mAXLG/a/pykPbtn0AAgL+1Zkk3emx1c+q+qlCJQMsWyPYBYADAxzA gQEODHAABwY4gAMDHBjgAA4McAAHBjgwwAEcGOAADgxwYIADODDAARwY4MAAB3BggAM4MMCB AQ7gwAAHcGCAAwMcwIEBDuDAAAcGOIADAxzAgQEODHAABwY4gAMDHBjgAA4McAAHBjgwwAEc GOAADgxwYIADODDAARwY4MAAB3BggAM4MMCBAQ7gwAAHcGCAAwMcwIEBDuDAAAcGOIADAxzA gQEODHAABwY4gAMDHBjgAA4McAAHBjgwwAEcGOAADgxwYIADODDAARwY4MAAB3BggAM4MMCB AQ7gwJ4Kp7W2FGsj7FeHPQDOf/9a2n9ZCjh/ra0FnAWcP3nB8TpYqoXzl+UF5w/gLOD8yQuO z8FSHpwf8vfvl8XOSOA6Yl6Tr5/xm/w3rdlPiIOlPDhf6mEB509KONPn7sPxOFiKg/MjN9wK TnzXcYPz5xFw5C4g6kv+k2GOfG3B+ZMCzs/PuApf44+/8mv8ZVzDcZXUt6sHS6Fw9K5Qjy/1 bAtOdNdRcMZPl9/UGqlnZpXeg6/XwVKq58hdMaXgr5/tsBbddYQ+TAyMr8WB8rUOvV4HS7Fh jUxhjZgItxqR+xdNrsP5IV/rsOZVUypUEPzon7M4+NmWBTfBMc78ccT8qR2OltI/f8lxzkkP Z/GLTkRPhKMHoSObQ7WWFI4OY/oXGXC1aCN/nwfHxeLDcTLAARzAARzAAZxnwRFtpC9XOOMw 1OMrHpytT2PwnHw9B3DixAfASQ1H2AbsUnNOXXDEAkgFgqASOIYJq0utQRAg50SGIwAHcADH A0kaOMg5UVYecNKHNQY4UGvIORAEgAM4qXMO1BoEAeAADtQacg4EQZbWullsOI6r09YNJ4kx 9+wTxwrLOYnhDIADOICTqwnknHx9CHAAB2oNOQeCAHAAB4acA0EAOIADtQZBAEEAOIADtQZB ADiAAyRQaxAEgAM4UGvIORAEMMCBWkPOgSAAHMCBWoNBEAAO4ECt1ZRzsll7wAEcGHIOBAHg AM5o/4bfPXt73++/Xbu2t24Oz9nmnDaMsXvWvnI4310Q+wacfOFkU8SsKufc6DmJfei5cBjg 1OU5UGuX4BDa8XieA0FwBQ5XD6i1LOHQ8YtDreWZc6j2HiK/1D+otdzg0I7STj+g1nKD00k4 3SEaqLVbco4Ka/Q8rEGt3SMIVDw78x3A8dq89qqUptwi53wP2VuGOUcMbXttEDqyiRPWHH3o 96hx9HveV8oSjuzZsLJraw6Xx/0tDY7cOlZybU1Yr8f/iso5Yj74WG6e43DrqcrhqNjwADi/ JcF522sbeLJotiXxnAxzzuqQ/tAGN07wcBAEz4DzkXzKUGtvRQvPsFYCnBWewtQancfHNQgC tjNuKFQQPADOQhuUBofqYgWh8ovqVhOhZcI5eIfO4ntwOCGHh+hNam3Eocp8uuxHVKtp2Usv ShCI46oI24Xj0KJOKghMBZa/+oBvEx2KEgQnmy1YiXBk43wMZmSCQ0iFnqNyDue0M/GbmNLz 1LwhlFIu/84pzUWt6c6FCWuT52QpCM5PbLGAM8dvMm26zjmdepHLv1NOsxEEr5xjPMc25xQJ 5xW/l3A6CUaGEHOE5gRHhrVRran1yletncNhdnCIEUFksZ26RR0RzuNra3Zw+Mtz1vMHLOHE nbf2cDhkHdbe4XCaiVp7IBwTv3UEN1OiCFEiTcE5V2vs2sqxBHBKzDl2Gx0ZzgA43nDo3XAu 3vk4TzjnatUKzvG0qELU2v7OuinnBIITvfDJACciHOYWpwAnOZzWG8kj1ZoVHO4m1TY7PUxm 7fRqbapo0OfB4Zvdts1mAhsEG5LD4booWKjnsGRwREy9FgZOiTmHcH06AdEltqmtI3+hultP zfNlp0f171+tHq/JbvbDF/1RuoFBtbLn0z/Z6aDTqlQGRzVtdHHzra1DzIlTvJufLzs9kumi 1cOuTSs8FQTcrAzldFmHJeq8LtLRaVWqgzNVpZfFadPR6l5wFlUC1SV+NSMD5JxzOB3v1p+p jpRF803+Upkg2IIjRZDeYrIFRxNbwYmr1rg5OVWX0BddJ/44ODq1vIe1GQ7dgXNlnGMFh74+ 810QPAEO/QxrKpYfw+ETnCbetTrF9FGrsLaCU1/OkS1qo9bmbrVSZzr9yi2eni87PRMco9bY 0DdRBYE5OdXEt0niywBHZpcqTK0F6+ec1Q/Y0ESFY7sqgLPR6tFh7d7aWmk5Jz4c0+q5CGcI AUeuCuBsV6Vvh/PYOQRR4Axp4TxREISA88hmm8V03IMGDp1r03T9R8LfrpADOHHg8J1Wwe5z unpFDkizUGtVTmQPBCfC2j8ejq5x0mmyvjnlQLZO1KuyAk3U0FyLZn0NKWLO2yE6wFHMWwsL x5T4v9W+pWR5mgvXHRLdeDNlK12c78zV17g5b0f+RrzhPF2tiZPDkUk4fC57Lsrwc8FzOoXM wJnOV1oUS6/DeaYgONls0S7gzKdW0k04uouiuz0Gjv5N0gSc0JstVp7TnXhON3lON3tOx4MI gmeqtYN3yBPdmVZrtNvIOe9wpi5KyLD2dLW2/w45I0OoE3aNIlirtQUcSk0XhZoLGRs4pgcE OGHhKM0pBdv3xikefPeMD7r3MtRaMHxmODBfXuV2OA8VBGIr2Sz+9K2mOq32+ulZhh8VBMAJ Aud1tTUWtip9BYlIASe/nCP20BxVpZPDGQBHSzTAyRLOVlkwi2t8pil85pdzXqu0veJ5wBG2 kLwcL3s4ezOZS4LznjBFLXD272Vw53WlHW89Jd4/RrShdtFtOWdgH2gIycRz3O5utD4G6oCz Oqz7t3Z/MXDEGg5jrHg4HzogHzhDWjgZ5pwPm+D06ryAYgTBGo4YmNBbUyWcpi8OzvABh1QK Z7gbjrgIZ3z0fYA9cl/OKQKOpVhr3zZdPoYK4PR1wGGAk6daW490md74ogRBf/7qOAjtzaMg QfBZGiwSTq93fkP0r71+Pj4jjfpRZm2tHaqA0wyNhEPkL+OvjXpuXmzWJwOUotbEcBnO7TmH ECJPa544GC5qE9Swpsmz8Ol12BcHZxnWxseIysDpx5i2FdbW+4vZxoIAZUdx7a161cwWlgJn eEUwxcV8mxzoeKTHTmAt3ppy5LwLpzdbWGjOMd/67ZxzKFePEIiLV/Fy8yG2/VpTFpxh0MKM zGrNfGvOw9pG8mD7cMQQ7uqEwufvCs6YYnv14/wSIjnV1pwDsXCCMzB2lY69WmM7/116jgoL KlIUVCEIAUeI/Y+QRWGx/4HNdX85eaPoR236gtMAzkf95MoHXoSz8BwZxkutrdnD+fAONs85 6Nf7Rqw0YrQIzU7h2Hx8Cf2cQz3Qfux/Nre1yce+YcvRlVYcowzRhaKmd7gCm/D56yrnPBGO eLW1PzZWLAV8b9IyMftKd1pDwGEH/0nDUUfDw+CwJZzhE860vbpotBr69qelFUu1JgJUf4rP OVslshM44mPo25iykRucAXBO4bCtD9iFs1iBFZze1XO8NvJZcLY/4BCO2IFj5TkX85EItbMK yDl7JZJDOAvBRkxaVmGtd4MjfPbpk+AwLzgirnccXr0n1IeQMh1HETNzDsLDETbxORycgnMO 8/wAFsVfrmGrDY7w/QARF44YAGe/tphWMbos/Tk5h8U4tq8zEAPgHNQW07gO4LjvHDHEdB0L tcZiu2xEOCLycoQj2T7w2osBcC7CEZ6bKXwd+llwLtYWp//e9yk37yE5R1zM9cIvrF0Uiw+B w47/0JPhpKvJ4sBhgHOwlXrvNMMZHOEH5+TyuGIICqfMnMOO/tLbwFk03QIWOBjgnMLpTXeG HCR8EQGOGADnaCHGc/ppPnxzsp/DqrXAnlNkzmFHf1ITa2Y4Z1seVhAAzllRfvYcdSKW92Hu A0cADrOE0xw7Brv00V6tvsyvGiXiLmIF59BzRNjjwmaZgDNMcNQ5WGF3FeBc2EEi8bo47n4W aGdlm3MCFuVZeAri2XACFuVFhNVgT4YT9NBk/khSwCku5+QCx2v9AOdeOIdvqR1OGjkUaQtr zzm5wGGAUyCc47Js1XDCDsGFPxKv6eqV55xEMygu7V0GOICTHRx2L5yLS60852QDx2s4AzhR R6FW/1M8E07oiWH+N+ryKtPUnXPygTMATtxhTjQ4AnBugHNxuXXnHJYNHK8BF+AATiVw/K9G 4xVgq845YsgGjteCnwxHDNnA8ZpLDTghxWNkOGXlnOBTkUW0o0wAztU9HQ/O5rqKx8LxuU9B NLW2/YZQUTSTnCOv9Wj5n1l4X7z0dlY9nGZ5okCEa5dEnHQAOJeC2hD12mui+pwzwZE3Poox mZJFPMrYU+CoG5oEvAhgCjjiMZ5zDMf7jlLeOScFnFJyzgkcbweIOguRPQhOjAs2R4UjAGe4 cpu8eMW1LfSV5Zx+vttAE2zGURA4AnCsGIghVzji8XAu3fvTe3cJn1WuLOdYwGHDHXC83l8v HBEeN+DEhRPshsYpQnG9OefCnInff3tm9aZ//lRFzXCaFwTmdeSru/BetW9/l2MVwunXhLbh nAc10QUw5qvWVu8rNOc0fnAsrqgRAs63/96tBA5p9PVs1Q/S9P10w+he9XKEXyExlud4SYJi 4Zh7dvbTJQb71w2jGw1H+Ci1sJ5zcYuLzDk9IUTfhH663bm+Z+fi9udbcGyUWljP8dnPi9uV h5pgmlgQ6OqzgdObW0lON4xWcJhfGfEYDiG0o16e4wJnXvMa4AyG0ZvnMOE1/DyEw+WXgkOd c47LnHZfONnlnNeP+YbRGg7zqqkFgXNBrb0JzXLLN0atmbAmrzo83TBaqbXWc4h+AkdyIZST aGpN/qfy4Rxby/xqaic5Z/QYyif3CabWlvNUpR4QZeccZ6q2If9ErXFqA8d1/LucCjkeRa90 yeqE82Hb9UhnKc19PccWjnScCuC41yh/gwgCB88RbnB6dYuYdmg94WSUc5zHi/8bboQz2MDR N1NoZ6UJOM6D0PEbCSqlZzjmZ/tEOFfD2oXyjRMcsQHn3/g4W/+cck56z7kAxyrniP8cJ03A iVOVtoPDL7l+bnA4Id20RdvjdnpjWLNUa3IQKqtOp3AKyzl6yK6V1HvFmH8QSh/WRNhgUDAc /g7EE06ICR6AM8ORXIisRprQxjk1L3CpescfplCZLKx9X4rU/nDyyzm6jK+GhgoWHVmYF/R4 UT/PWa3VCmccGH7A0SN4/cJyRH/rOMceDiFkqWRouWqtUznnA46MbvKFcTsXcK4cu7I4cN5m 268Q2MOh3aKhRzPOOYdnRL8EwQRngUkzevecC3BeTVAnz2Eex1uVcJSUnsOagUMChbXUcEwR b4wA+ndSIhw9CJVRjGpxoOOZekGGNeM5xN5zKJk0H1f7pTO5S7466j8q/0540Nra1vHG344y og6M8gRB6PINMf4nH/w1WtIdanUMU25blfYWBLOoeUWC2uFYhTW9H3RUXMAxHerRc2bxEUmt yRWQAYEqOfMG5/fpnqP3jYFDyKpD7QiHecFZSBonz8kt58SBQ2fPWTdB7eEIf0Ewy0zyIDjW YY3ydVhbwTmft6YbZhfVmsZDaIFwnAuSFh9lwhqdlPik1tQglBg4FmqtZREi9YPVmjrWLRd6 BqdFbS1wWBOt5ULPcs6WjwLOVUHQWi6U0BM4vlZUPye1WjvbPZblG9+5TeLBcH4tFEWYlsE0 uckVziVFkxcc7ghnr5vsHNbOC5/i8WqNBw5rRhBQN6n22elhRl08WhDoIosqE9MAcNrhBM7m SW0bzQS0qZXnLFo2V6W0PtQDw3G4mUFtgmAasNvCsSNOdWdIF03mto6ew6PaX9w8X3Z61POp 1XOt2VYdHELCFT75Wz91auuoOTz6xfn5otOjmE6tHsB595wQgqB5r0p3i+I0X7a/5ueLTo+p HGsfvtYJrUetyVZ0oLDW78OZe5Oq/bWGo4mdwLHLOW09ZxnIeQOdg1o7rq01B57TLSfyvMPh IeFUNuOzs54T4xrW+GdY0/2VYzg65/SPV2tR4HAyq7WpW61+V6Jdtb/m54tOzwRnUmsEtTUZ 2ELDuWoKTt8DTtjyTQg4U87pH6/WMoSjpMkWHAE4GYS1DnAKgfNstZbrqe6egqCiZlt1cCJZ BfPWYsBJa7hIhOdphwJwAKdqOEGvQ+Cq1irKOQV4znMFAeAATpicA7UGQQA4gFMFHJEUDnKO JxwIAsABHKi1CIN5CIIMTdif2ww4d/gYuwXOY9WaYwBkkWLlYeHzsYLAwa70eK8dFoCTL5w8 DoW8b27kENdK9iHAAZxa4PjcKPRpOee2pANBADhlw1GBDWotX7tZETDAyTfGAM7t+wdqrRzX gSDI2HUAx2FfvRY330m9gVrLbvVftxyGIMhOE0xwGsDJz3Xm29w3iXYX1Jr9ApPDgSCw312A k2OkblPCgVrz4p0cDgSB/SYATsauIweh8gG1ltfxJlJ7KQSBuyYAnCwjdR7n0SLnZHNAQxAc e3fTT+mfAU5e1suvJq3rQK1ZWfMGRy73zjmYgLOCQxoV1noi2wSCAU5enqPgjA+id1t1mq3Q nNMTQl5wGo09LRwIAgvPIUTDEYljDuBYhTWjCljac2ih1uxyTqPvnZdif2WR10hiT/Ua58xq bZDnHSSZPA04ftay2s47uDvn/Bt+/61eGF8azWdbDuCMn/JbnA/dCSfkxcqFy9UEAOfcvgNe 5l8kurxQFteLSJFzvv3vx5YBnOHBcAbAeRKcb6i1UDkn07CWZFAAQQA4FnCo+ccvw/lYEn1b KtSae87ZgfMbBs50N0kIAi84071Tr3vOx5Le4XwDjh8cPt3SdroptTec5ZKoeUEvtLxGaQaC YL55NF3czt1LEKyXRLvphtQQBBfgdMHgdJ9wOsDxhsNlOCJmlxJyYZyzXhKd4xzUmmeFgKs7 udNFAPL1nPWSjNNQCAL/8o28kzv3D2viNQhdLSlCznkiHE7l3iQrtSasdoXq/YitJRFCdFiD Wgtevmkt2Ug6KN+khWPXDDV9U8BJCUe4sGkZOqGRcs4mHNf7DaDZlhCOm+e06IQGhnMy+8Yt 5ySfffN0tWZNB2otORw7LS0W4xzASQfHuUIAtZZGEPjU1iAIAAdwhmG6DFRWcKDWDBySNZzK BcHJOKd38pzk45yHq7Xp6nYkI8+BWnuHQ2yubwdBcA+cBnAAJ0Nj+eecPOEIwAGcfOE05pEN nCwuuIbyzX3+AjiAc7xxZV+HoHK1VrgxwAEcwIFayyWhQhAADuA8Ma0h50AQAA7gQK1BEAAO 4AAO1BoEAeAADtQacg4EAeAADgw5B4KgVgHA5Jmpyy/ASWItO/9it3pOjTlHMKsdX8BxUhic i4d7as9rYxwn6eGUd7hXF9aGuw93wIEBDuDAAAcGOIADAxzAgQEODHAABwY4gAMDHBjgAA4M cAAHBjgwwAEcGOAADgxwYIADODDAARwY4MAAB3BggAM4MMCBudr/Ae4voyxsJcIyAAAAB3RJ TUUH0gITFQQLQh3BggAAAABJRU5ErkJggg== - --------------040803060708000001010007-- ------------------------------ Date: Tue, 19 Feb 2002 14:04:30 -0800 (PST) From: Chris Mungall Subject: Re: [microarray-ontol] MGED ontology update [GO folks; apologies for wandering a bit off topic but I think that it's good we have some cross-ontology chat here for the software folks, especially John, as a lot of this is really relevant for GOET] On Tue, 19 Feb 2002, Ugis Sarkans wrote: > > Michael, Chris, Jason, > > At MGED I said that I would like to see a metamodel of ontologies > before deciding how to solve MAGE+ontologies issues. I am > attaching a simple class diagram that is supposed to represent a > subset of OIL metamodel, just the features used in the current > MGED ontology for sample descriptions. In general the idea of > adding "Slot" class to MAGE seems to be right, just some points > about terminology. On the Individuals level there are Instances > and Relations, "Slot" is a Class level concept, so probably > in MAGE what we thought would be "Slot" class should be called > e.g. OntologyRelation. Actually now I think OntologyEntry is not > a good term, it is really not clear whether we want to model > entire ontologies or something else. What about something else, > like OntologyInstance or OntologyInstanceReference? The diagram you attached is very clear, thanks. I agree that OntologyEntry is a slightly confusing class name. I am still unclear about the connection between the diagram you just sent and the UML diagram Jason sent. Jason's is the official MAGE UML? Since the diagram you (Ugis) just sent seems to map pretty much directly to equivalent OKBC (semi-standard programmatic API for KBs/ontologies) classes, why not just import it directly into MAGE? A major advantage would be the ability to swap out the standard MAGE default implementation classes and put in protege/OilEd java classes conforming to the same interface. This may be easier said than done, I've never tried this, so it could well be a lot more difficult than I imagine... Tool interoperability would be pretty cool, and I don't see the point reinventing the wheel and giving non-standard classnames (as in the sense of UML classes) for everything. I don't know much about the MAGE effort (which probably shows), if it has already progressed quite far then maybe drastic changes to the object model would be too disruptive at this stage. The UML Jason sent seems like it would work but I'm still a little unclear on the mappings. One final question, on a slightly different topic. When you import/link-to GO in MGED, do you treat the GO terms as instances or as classes? (I'm using these words in their ontology sense now). Treating them as classes has all kinds of problems (protege allows metaclasses which helps somewhat, but seems nonstandard) so I'm guessing instances of, say, a GoTerm class is the way to go. This is relevant to us as we'll soon be exporting GO in DAML+OIL and RDFS for use in ontology tools and we'd like a standard way to do it. (Brad Marshall was way ahead of the game here and has provided GO in RDF for a while, so it should be easy to transform in a number of different ways with XSLT). Cheers, Chris ------------------------------ Date: Wed, 20 Feb 2002 10:23:42 -0500 From: Chris Stoeckert Subject: [microarray-ontol] follow up to MGED4 Hi Helen, I'm cc'ing the group to let them know what's up with the ontology. I've come up with more changes to the ontology resulting from our working group discussion and continued discussion with the MAGE folks (although I'm delighted to claim Jason, Michael, Paul, Charles, and Ugis as Ontology folks as well! ;-) ). If there are no objections from the group, please make the following changes to the version of the ontology we worked on at the meeting: 1. move culture condition from environmental history to treatment reason: culture conditions may have protocols. protocols cannot be applied to biosource because it implies a change or event can happen to biosource. associated changes: definition of environmental history should reflect this restriction (and can be made explicit with a constraint). 2. add the slot "has_batch_ID" to compound reason: batch IDs are commonly used in specifiying compounds 3. add has_ID to BiomaterialDescriptions . reason: for reference need a unique ID which can be tracked and used as a pointer. ID can be retired but not deleted. issue: how to give IDs to all individuals? 4. change BiosurceProvider to model SourceContact association in MAGE. MaterialType association in MAGE = biosource_type so move to slot for BiomaterialDescription (or subclass ?BiosourceProperty) Please send me a html version and I will post it at the ontology web site. Please post the rdfs and DAML version at mged.sourceforge.net. Also please send the MIAME to MAGE mappings that Susanna has generated to replace the old MIAME to MAML mappings I have up. Someone (Michael M.?) mentioned that MIAME to MAGE mappings had been done for the OMG submission but I couldn't find them (I scanned through the Gene Expression RFP response doc). Finally, please send me your slides from the working group to post (I will send you and Alvis my slides). I've also started to look through where our classes overlap with MAGE and see if there are conflicts. I think the following are OK: Contact BibliographicReference OntologyEntry Measurement CompoundMeasurement BiomaterialMeasurement Not sure yet about: Protocol (? link through OntologyEntry) Treatment (? ranks, Action) Compound ?move treatment application and protocol. distinction between MAGE biomaterial and BiomaterialDescription/BiomaterialState Will also work on cleaning up the web site as requested. Cheers, Chris ------------------------------ Date: Thu, 21 Feb 2002 14:18:04 +0000 From: Ugis Sarkans Subject: Re: [microarray-ontol] MGED ontology update Chris, > I am still unclear about the connection between the diagram you just sent > and the UML diagram Jason sent. Jason's is the official MAGE UML? Jason's diagram was the proposal for changes to MAGE that would allow better integration with ontologies (MGED ontology in particular). What I sent was just something to illustrate structure of ontologies (or, more precisely, OIL). > Since the diagram you (Ugis) just sent seems to map pretty much directly > to equivalent OKBC (semi-standard programmatic API for KBs/ontologies) > classes, why not just import it directly into MAGE? Because in MAGE we do not want to model whole ontologies, we just want to have a way to refer to ontology terms (individuals and relations). > A major advantage would be the ability to swap out the standard MAGE > default implementation classes and put in protege/OilEd java classes > conforming to the same interface. > > This may be easier said than done, I've never tried this, so it could > well be a lot more difficult than I imagine... > > Tool interoperability would be pretty cool, and I don't see the point > reinventing the wheel and giving non-standard classnames (as in the sense > of UML classes) for everything. MAGE in essence is an ontology, and we are also providing a generic way to refer to other ontologies. We were not aware of better, "standard" in some sense, classnames for the domain that we were modeling. And the main purpose of MAGE was to obtain MAGE-ML, so too much generality was not considered good. > I don't know much about the MAGE effort (which probably shows), if it has > already progressed quite far then maybe drastic changes to the object > model would be too disruptive at this stage. The UML Jason sent seems > like it would work but I'm still a little unclear on the mappings. Yes, too drastic changes cannot be made for this version of MAGE. > One final question, on a slightly different topic. When you import/link-to > GO in MGED, do you treat the GO terms as instances or as classes? (I'm > using these words in their ontology sense now). Treating them as classes > has all kinds of problems (protege allows metaclasses which helps > somewhat, but seems nonstandard) so I'm guessing instances of, say, a > GoTerm class is the way to go. This is relevant to us as we'll soon be > exporting GO in DAML+OIL and RDFS for use in ontology tools and we'd like > a standard way to do it. (Brad Marshall was way ahead of the game here and > has provided GO in RDF for a while, so it should be easy to transform in a > number of different ways with XSLT). I think we just want to link to instances. Regards, Ugis ------------------------------ Date: Wed, 06 Mar 2002 10:04:26 +0000 From: Susanna Sansone Subject: [microarray-ontol] [Fwd: Mapping MIAME to MAGE-OM and MGED Ontology - v1.0 Draft] Dear all, Yesterday, I sent this document to this list and the annotation one (see message below). But apparently this list hasn't received as the attachment it too big! Now for your view, the document has been posted at: http://www.mged.org/Workgroups/MIAME/miame_mage-om.html under: 'MIAME to MAGE-OM' Note= The MIAME Glossary link in that page contains the 'old' glossary to be updated and completed. Thanks, Susanna - -------- Original Message -------- Subject: Mapping MIAME to MAGE-OM and MGED Ontology - v1.0 Draft Date: Tue, 05 Mar 2002 17:44:47 +0000 From: Susanna Sansone To: microarray-annot@ebi.ac.uk, microarray-ontol@ebi.ac.uk CC: Susanna Sansone Hi Everybody, Please find attached the first draft of a document mapping MIAME to MAGE-OM and MGED Ontology. At MGED4 has become very clear that the boundaries between MIAME concepts, the MIAME-compliant MAGE-OM and the MGED ontology- that try to define and structure the MIAME concepts- is neither well defined nor easy to understand. Here a document written on the example of one previously done by Chris between MIAME and MAML. This contains MIAME concepts definition, how its requirements map to the MAGE-OM and where the MGED ontology already exists and where there are descriptions that still require inclusion into the ontology (as also highlighted by Jason). The document also contains a glossary for MIAME terms, listed in alphabetical order. As I said, it is just a draft and comments/suggestion are very welcomed before posting it on www.mged.org/miame . It will also be updated as the MIAME v1.1 (just posted) is approved. Thanks, Susanna - -- ******************************* Susanna Assunta Sansone, PhD Microarray Informatics EBI - The European Bioinformatics Institute EMBL Outstation - Hinxton, Wellcome Trust Genome Campus Cambridge CB10 1SD, UK email: sansone@ebi.ac.uk direct: +44 (0)1223 494 691 fax: +44 (0)1223 494 468 http://www.ebi.ac.uk/microarray ******************************* - -- ******************************* Susanna Assunta Sansone, PhD Microarray Informatics EBI - The European Bioinformatics Institute EMBL Outstation - Hinxton, Wellcome Trust Genome Campus Cambridge CB10 1SD, UK email: sansone@ebi.ac.uk direct: +44 (0)1223 494 691 fax: +44 (0)1223 494 468 http://www.ebi.ac.uk/microarray ******************************* ------------------------------ End of microarray-ontol-digest V1 #20 *************************************