- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 8 Aug 2012 13:54:39 -0400
- To: Michel Dumontier <michel.dumontier@gmail.com>
- Cc: Peter Ansell <ansell.peter@gmail.com>, "Robinson, Peter" <peter.robinson@charite.de>, Chris Mungall <cjmungall@lbl.gov>, HCLS <public-semweb-lifesci@w3.org>, bio2rdf <bio2rdf@googlegroups.com>
- Message-ID: <CAFKQJ8=mj=SZd2JQ0Gw4my-Rnp1U5+mEeUmUsJGFZCccg_zMqg@mail.gmail.com>
On Wednesday, August 8, 2012, Michel Dumontier <michel.dumontier@gmail.com> wrote: > Hi Alan, > > > On Wed, Aug 8, 2012 at 10:00 AM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote: >> >> We have discussed that the OBO Foundry policy is to use CC0 or CC-BY >> and it has been put to the GO that we would like to migrate to that >> license. I don't know the status of that discussion. >> > > We certainly welcome the adoption of standard licenses for OBO ontologies. > >> >> That said, I would be strongly discouraging of (but unable to prevent) >> any "no-blank-node" rendering of GO ontologies, and in particular >> would note that such a transformation would render any OWL we publish >> unsyntactic. > > Not sure what you mean by "unsyntactic". > The objective here would be to provide an RDF and SPARQL friendly version of OBO ontologies. It would reduce the ontological commitment to RDF, so in this sense, it would be a semantic loss, but makes it easier to retrieve relations between entities. We could always provided links to OWL versions, if they are available. There have been discussions of, e.g. Skolemization of existing resources, and those transformations are destructive. Reducing to RDF would not change the ontological commitment, but would lose information. In any case such a transformation should not entail minting new Uris for all resources. In addition, I question the value of transforming the ontologies in this way, given the disadvantages of not encouraging a uniform, author provided view on the resources. The OWL resources are SPARQL friendly enough to build onto bee displays. If you look at the bottom of the page there are links to see the SPARQL queries used to construct the pages. A more constructive effort, in my opinion, would be to build SPARQL parser extensions along the lines of TERP that make it easier to query the ontology as it is. >> Further, the OBO ID Policy has been, for the most part, been put in >> place and we do not use hash URIs and are moving to having all OBO >> URIs resolving to page per view. See for example >> http://purl.obolibrary.org/obo/IAO_0000032 >> > > does the OBO Foundry automatically check conformance? Is there a report page for each ontology? Conformance to what? To the OWL Spec? Yes, I believe it does, through the OORT and Jenkins build tools, but I'll leave it to Chris to detail that. If there is something you are looking specifically for I expect it could be provided. Or you could collaborate with us to build such services. I believe that collaboration towards building a stronger single distribution is a much better way to spend effort, in the long run. >> So the Foundry is already in the process of making all of the OBO >> available as linked ontology data. I would suggest other groups join >> this effort rather than setting out to duplicate and add confusion by >> having a parallel set of identifiers for the same set of entities. >> > I know about berkeley's download page - > http://www.berkeleybop.org/ontologies/ > is this what you are referring to? We are moving towards completely using Web standards. Eventually, we will have all OBO ontologies available at http://purl.obolibrary.org/obo/<namespace>.owl . This, and other information about deployment is in http://obofoundry.org/obo/id-policy.shtml, which describes what we are trying to put in place. Again, we are making progress in this effort, but help could certainly be used. Chris pays attention to where ontologies are before they arrive at their documented location. I attend to ensuring that once there they behave as expected according to web standards. If you look at http://www.ontobee.org and select an ontology there should be metadata about where the ontology was downloaded from to get it into Ontobee. >> In fact, there have been a number of OBO participants who prefer the >> the current GO license precisely because it prevents this kind of >> duplicative, confusing practice, a practice that is discouraged even >> by the W3C standards these groups are chartered to work with. >> >> For more information about OBO efforts in this area, please see >> http://code.google.com/p/oboformat/ and >> http://code.google.com/p/owltools/ >> >> -Alan >> > > I don't see RDF or SPARQL endpoints being provided at either of those links. Indeed. They are not where you would expect to find them. There are two sparql endpoints at the moment, each with different approaches. We are working toward deciding on and documenting expected behavior and then ensuring we can provision them well enough to stand up to regular use. Understand also that we are coming to the end of a multi-year effort to regularize our URIs, defining a proper OWL translation of OBO, and providing a new BFO to be the basis for these ontologies. We are not quite finished. I would be most comfortable publishing a stable endpoint once this transition was over. Again, assistance in deploying mirrors and in helping with all the various loose ends needed before the resource can be considered stable would be very much welcomed. http://sparql.obo.neurocommons.org/ intended to serve ontologies using the legacy URIs (needs to be reviewed - hasn't been in a while.) http://sparql.obodev.neurocommons.org/ intended to serve ontologies using the current URIs (same as above) http://sparql.hegroup.org/sparql serves the ontobee server (not meant for wide consumption, but useful for prototyping) Members of HCLS who wish to assist with maintenance of the Neurocommons endpoints would be welcomed. Once they are reviewed and brought up to date on which ontologies they load, the Neurocommons RDF Bundling system will provide an addition distribution mechanism for creating mirrors. So Michel, and other HCLS users, consider this an invitation: The OBO Foundry is very close to providing a stable, well thought through process for semantic web deployment of OBO ontologies. We could very much use technical support in finishing a number of technical loose ends, in providing tools that build on these efforts, and on making it easy to access existing endpoints or provide mirrors of the content. If there is sufficient interest in this within the group perhaps Chris and I can schedule a time when we could meet with those interested and see what the possibilities are. Sincerely, Alan Ruttenberg http://alan.ruttenbergs.com > > m. > > > On Wed, Aug 8, 2012 at 1:36 AM, Peter Ansell <ansell.peter@gmail.com> wrote: >> Hi Peter, >> >> I understand completely. The usage policy is very liberal in terms of >> distribution and we are glad for that! >> >> Would it be possible for us (Michel and I) to make suggestions with >> the goal of publishing a version that matches the no-blank-node policy >> that Bio2RDF attempts to follow and uses URIs structures that can >> resolve using http://bio2rdf.org/. We don't want to make material >> changes to any of the terms but we would like to make the resulting >> RDF graph browsable as Linked Data, as far as possible. To enable that >> we need to directly resolve URIs for items to their definitions, by >> replacing fragment/hash identifiers with >> http://bio2rdf.org/ns:identifier equivalents, for example. >> >> Thanks, >> >> Peter Ansell >> >> On 8 August 2012 15:20, Robinson, Peter <peter.robinson@charite.de> wrote: >>> Hi Peter, >>> >>> given that the HPO is being used by medical groups for real patient data, we think it is potentially dangerous to allow external groups to change the data and present it elsewhere, given some of the notorious difficulties in actually understanding what some medical terms mean (even for us MDs). This was the reason for the license statement, which other than that is quite liberal. However, we would be happy to work with you to find a solution, which could forsee us providing RDF on our website which you could import. >>> >>> BW Peter >>> >>> >>> >>> >>> >>> PD Dr. med. Peter N. Robinson, MSc. >>> Institut für Medizinische Genetik und Humangenetik >>> Charité - Universitätsmedizin Berlin >>> Augustenburger Platz 1 >>> 13353 Berlin >>> Germany >>> +4930 450566006 >>> Mobile: 0160 93769872 >>> peter.robinson@charite.de >>> http://compbio.charite.de >>> http://www.human-phenotype-ontology.org >>> Introduction to Bio-Ontologies: http://www.crcpress.com/product/isbn/9781439836651 >>> ________________________________________ >>> Von: Peter Ansell [ansell.peter@gmail.com] >>> Gesendet: Mittwoch, 8. August 2012 03:03 >>> An: Chris Mungall >>> Cc: Michel Dumontier; HCLS; bio2rdf; Robinson, Peter >>> Betreff: HPO and Gene Ontology Licenses >>> >>> On 8 August 2012 02:46, Chris Mungall <cjmungall@lbl.gov> wrote: >>>> Hi Michael >>>> >>>> I can't seem to connect to the triplestore. >>>> >>>> Have you considered adding associations between OMIM and phenotype ontology >>>> classes? These can be downloaded from >>>> http://www.human-phenotype-ontology.org/ as tab delimited files that can >>>> trivially be converted to an rdf model of choice (we will be providing OWL >>>> for this ourselves in the future, it will likely differ in modeling and URIs >>>> from bio2rdf). >>> >>> The HPO files cannot be modified though given the following license condition: >>> >>> "That neither the content of the HPO file(s) nor the logical >>> relationships embedded within the HPO file(s) be altered in any way." >>> [1] >>> >>> in the same way that Gene Ontology files cannot be legally modifed >>> using a very similar license condition: >>> >>> "That neither the content of the GO file(s) nor the logical >>> relationships embedded within the GO file(s) be altered in any way." >>> [2] >>> >>> Therefore Bio2RDF should not be converting the HPO classes to RD > > > -- > Michel Dumontier > Associate Professor of Bioinformatics, Carleton University > Chair, W3C Semantic Web for Health Care and the Life Sciences Interest Group > http://dumontierlab.com >
Received on Wednesday, 8 August 2012 17:55:38 UTC