<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Im not sure how many of you follow the mailing list <<A href="mailto:public-semweb-lifesci@w3.org">public-semweb-lifesci@w3.org</A>>, but here is an interesting recent posting regarding LSIDs and ontology documents.</DIV>
<DIV>This group is currently in a similar situation to us, debating the best approach for GUIDs and sorting out ontologies. It includes the BioRDF group that Suzie Stevens spoke of at the RDF workshop in Edinburgh (for those of you who attended).</DIV>
<DIV>They are looking at LSIDs but as always there are people for and against the technology.</DIV>
<DIV>The thread started by the following post goes on with some interesting arguments for and against using LSIDs for identifiers to "ontology fragments". You can see more at <A href="http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jul/0076.html">http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jul/0076.html</A>.</DIV>
<DIV> </DIV>
<DIV>Kevin<BR><BR>>>> Mark Wilkinson <markw@illuminae.com> 14/07/2006 5:01:33 a.m. >>><BR></DIV>
<DIV style="COLOR: #000000"><BR>Hi all, <BR><BR>I chatted with Sean Martin yesterday and he indicated that, on the last<BR>SWLS teleconference, he mentioned one of the ideas that my lab and his<BR>group have been tossing around for the past few weeks v.v. LSIDs<BR>representing ontology nodes. He asked me to fill-in some more detail in<BR>a message to this mailing list.<BR><BR>In a publication that will be available soon [1] we (briefly) discuss<BR>the problem of actually *using* the currently available ontologies in a<BR>"real" Semantic Web setting - i.e. dynamically downloading whatever<BR>ontologies are necessary given the predicates that you find in some<BR>discovered RDF instance document. The OWL representation of GO is over<BR>10 Meg... for heavens sake!... and GO is a small ontology compared to<BR>things like the NCI Metathesaurus.<BR><BR>The problem with using document#fragment URLs to identify ontology nodes<BR>is that the defined behaviour for resolving such an identifier is to<BR>drop the fragment (since that isn't available server-side anyway) and to<BR>return the entire document... all 10Meg's of GO... each time... We<BR>would argue, therefore, that the URL (if you adopt its default<BR>behaviour) is not only a bit of a nuisance, it is a blocker in some/many<BR>cases.<BR><BR>There's been some exciting work in the domain of ontology segmentation<BR>[2,3,4,5] that, we believe, is perhaps a more rational way of working<BR>with these massive ontologies when you need to get on-the-fly access to<BR>only the portions of the ontology that are relevant to your Blackberry's<BR>agent at that moment. I know that others (e.g. Damian Gessler and<BR>collaborators at NCGR, but I don't have the reference to his submitted<BR>manuscript at hand right now... sorry Damian!) are also working on the<BR>problem of segmentation by passing a self-inflating "flattened" ontology<BR>fragment. The problem is that there is no Semantic Web-style protocol<BR>available to specify that this is the behaviour you want, or for the<BR>agent to know that this is the behaviour to expect. Some of these<BR>projects are setting up the ontology fragment-generator as a Web Service<BR>(if I recall correctly, Rector's group does this [4]), however this<BR>doesn't solve the SW problem either because we can't (easily) model a<BR>Web Service invocation as a single URI (at least, not by any existing<BR>standard or convention... I guess some long REST-style URLs could do<BR>this...)<BR><BR>Here is where I think the LSID could really shine! Unlike a URL, the<BR>LSID does not have to return an entire document in response to a<BR>getMetaData call. Thus, if an LSID were used as the identifier for an<BR>ontology node, the behaviour of the getMetadata call could be, by<BR>convention or by standard, to return only the relevant ontology<BR>fragment, where that fragment was generated by e.g. the Rector<BR>Segmentation generator in the background.<BR><BR>These were just early thoughts we've been having, but Sean asked me to<BR>share them with the group in hopes of fanning the flames of discussion<BR>and debate. It seems to me to be a "blocker" issue when it comes to<BR>deploying SW applications in the wild, and I know that projects like<BR>Damian's Semantic MOBY have hit this problem early and hard, as have I<BR>in my own sandbox. It's all well and good when we play SW on our own<BR>local machine, but as soon as we try to play SW in the wi(l)der world<BR>this problem cripples us almost instantly. We think the LSID is (a/the)<BR>solution to this problem, but no solution will be useful if it doesn't<BR>have wider adoption, so... <BR><BR>opinions?<BR><BR>Cheers all!<BR><BR>Mark<BR><BR><BR><BR>[1] Good, B, Wilkinson, M. (in press). The Life Sciences Semantic Web is<BR>Full of Creeps! Briefings in Bioinformatics.<BR>[2] Noy, N, Musen, M. Specifying Ontology Views by Traversal. 2004.<BR>[3] Alani, H, Harris, S, O'Neil, B. Ontology Winnowing: A Case Study on<BR>the AKT Reference Ontology. 2005.<BR>[4] Seidenberg, J, Rector, A (2006), 'Web Ontology Segmentation:<BR>Analysis, Classification and Use', World Wide Web, ACM, Edinburgh,<BR>Scotland.<BR>[5] Stuckenschmidt, H, Klein, M. Structure-Based Partitioning of Large<BR>Concept Hierarchies. 2004.<BR><BR><BR><BR><BR>-- <BR>Mark Wilkinson<BR>Asst. Professor, Dept. of Medical Genetics<BR>University of British Columbia<BR>PI in Bioinformatics, iCAPTURE Centre<BR>St. Paul's Hospital, Rm. 166, 1081 Burrard St.<BR>Vancouver, BC, V6Z 1Y6<BR>tel: 604 682 2344 x62129<BR>fax: 604 806 9274<BR><BR>"Since the point of a definition is to explain the meaning of a term to<BR> someone who is unfamiliar with its proper application, the use of<BR>language that doesn't help such a person learn how to apply the term is<BR>pointless. Thus, "happiness is a warm puppy" may be a lovely thought,<BR> but it is a lousy definition."<BR> Köhler et al, 2006<BR><BR><BR></DIV></BODY></HTML>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>
WARNING: This email and any attachments may be confidential and/or<BR>
privileged. They are intended for the addressee only and are not to be read,<BR>
used, copied or disseminated by anyone receiving them in error. If you are<BR>
not the intended recipient, please notify the sender by return email and<BR>
delete this message and any attachments.<BR>
<BR>
The views expressed in this email are those of the sender and do not<BR>
necessarily reflect the official views of Landcare Research. <BR>
<BR>
Landcare Research<BR>
http://www.landcareresearch.co.nz<BR>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>
<BR>
</BODY></HTML>