obo-format — Discussion of the format, syntax, metadata, and semantics of OBO ontologies

[Obo-format] Call for Papers: 10th International Society for Biocuration meeting, DATABASE Journal Virtual Issue

[J. M. C. P. <ch...@st...>]

Dear Colleagues,

The International Biocuration Conference is a unique event for biocurators and developers of biological databases to discuss their work, promote collaborations, and foster a sense of community in this very active and growing area of research.  For the 10th International Biocuration Conference in Palo Alto, California, you are invited to submit your work for publication. This call for papers is done in collaboration between DATABASE: The Journal of Biological Databases and Curation and the International Society for Biocuration. The DATABASE journal will publish an online Virtual Issue of the accepted papers, see below for a link to last years issue. This is a great occasion to enhance the recognition of your work and of our profession by the greater biological research communities.  The Biocuration 2017 program committee will prioritize inclusion of accepted papers for oral presentations at the conference.

This year manuscripts are invited for the following topic areas:

- Functional Annotation
- Phenotypes, genotypes, and variants
- Clinical annotations, diseases, drugs
- Big data to knowledge
- Large scale and predictive annotation
- Data standards and ontologies
- Crowd/community curation
- Data integration, data visualization
- Curation standards and best practice; inference from evidence; data and annotation quality
- Biocuration and the scholarly communication cycle; data publishing and curation, data sharing


Papers on topics outside the above will also be considered for publication.

The manuscript review process will be expedited by the journal’s associated editors and they will thus need to be firm on the submission deadlines:

Submission deadline: October 31, 2016
First decisions: December 9, 2016
Deadline for revisions: January 23, 2017
Final decisions: February 25, 2017
Conference: March 26-29, 2017

Authors wishing to submit to DATABASE for the 2017 Biocuration Virtual issue should go to the DATABASE home page (<http://database.oxfordjournals.org/>) and click on the "submit now" after having read the "Instructions to Authors". Authors should CLEARLY state that they are submitting the manuscript for consideration for the Biocuration 2017 conference so that the DATABASE staff will ensure appropriate fast-track for inclusion in this meeting's proceedings.  In addition, within the database submission form, you should also select "Biocuration Conference Paper" as a manuscript type.  We look forward to your participation at Biocuration 2017 the 10th International Biocuration Conference.

Submitting a paper to DATABASE does not in itself sign you up to give a talk or poster, you must register your interest separately.  Information about abstract submission will be announced soon.

The proceedings of the past International Biocuration Conference, the Biocuration Virtual Issue, are online at
<http://www.oxfordjournals.org/our_journals/databa/biocuration_virtual_issue.html>

Kind regards,

-Biocuration 2017 Organizing Committee
bio...@li...<mailto:bio...@li...>

[Obo-format] oboformat project moved from googlecode to github

[Chris M. <cjm...@lb...>]

This is the new home:
https://github.com/owlcollab/oboformat

I took the opportunity to update the README - we now recommend using 
ROBOT for command line conversion, and the converter is part of the 
OWLAPI (3.5.x and above).

The HTML for the spec is now available via gh-pages:
http://owlcollab.github.io/oboformat/doc/obo-syntax.html

Given the spec has been mostly stable for a while, I would like to wind 
down this list and use the tracker for any proposed spec changes, as 
proposed here:
https://github.com/owlcollab/oboformat/issues/88

To subscribe, go here:
https://github.com/owlcollab/oboformat/issues
and click "Subscribe"

Re: [Obo-format] Problem converting from OWL to OBO

[Steffen N. <sne...@ip...>]

Dear Chris, 

thanks for the prompt answer, owltools did the job!

Yours,
Steffen



On Mi, 2015-03-04 at 09:30 -0800, Chris Mungall wrote:
> Try
> 
>      owltools nmrCV.owl -o -f obo --no-check nmrCV.obo
> 
> You'll need https://github.com/owlcollab/owltools
> 
> But as a general rule an owl file in the wild will need massaging to get 
> into something usable. The obo spec is a superset of what legacy tools 
> typically expect and I assume the obo conversion is for a legacy tool
> 
> On 4 Mar 2015, at 7:37, Steffen Neumann wrote:
> 
> > Dear all,
> >
> > In the EU project http://www.cosmos-fp7.eu/
> > we're developing a controlled vocabular / ontology
> > http://nmrml.org/cv/ for use in metabolomics / NMR.
> >
> > The current nmrCV ontology is located at
> > https://github.com/nmrML/nmrML/blob/master/ontologies/nmrCV.owl
> >
> > Since we are using tools from the http://open-ms.sourceforge.net/
> > team, we need to convert the nmrCV.owl into the OBO format nmrCV.obo.
> > Generally, this should work, as we do not use
> > and concepts from OWL which are not available in OBO.
> >
> > We have done the conversion successfully through the export in 
> > Protege,
> > but since we need this in an automated manner, Philippe Rocca-Serra
> > recommended in 
> > https://github.com/nmrML/nmrML/issues/42#issuecomment-25201303
> > to use obolib-owl2obo.
> >
> > However, I get some weird exceptions 
> > https://github.com/nmrML/nmrML/issues/43
> > which I am unable to interpret. This happened with both the obolib SVN
> > back in September 2013, and with the version updated today:
> >
> > I use: ./obolib-owl2obo nmrCV.owl -o /tmp/nmrCV.obo
> > and get
> >
> > Exception in thread "main" 
> > org.obolibrary.oboformat.model.FrameStructureException:
> > 	multiple is_obsolete tags not allowed. in frame:Frame(null ontology(
> >      ....
> >      [and then a whole lot of metadata from our ontology]
> >      ....
> > Ontology(
> > AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> 
> > "")
> > ){}))
> > 	at 
> > org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
> > 	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
> > 	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
> > 	at 
> > org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
> > 	at 
> > org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
> > 	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
> > 	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)
> >
> > The full trace is below. My question:
> >
> > => How do I debug / find out *where* these "multiple is_obsolete tags"
> > come from ? I don't see them in
> > 	sneumann@acryl:~/nmrML/code/ontologies (master)$ grep is_obsolete 
> > nmrCV.owl
> > 	sneumann@acryl:~/nmrML/code/ontologies (master)$
> > I am also not aware that we actually import any other resource,
> > in my local copy of nmrCV.owl I have commented out the only import we 
> > have:
> > 	<!-- <owl:imports rdf:resource="&obo;bfo.owl"/> -->
> >
> >
> > Or did I miss some constraints, which would make my attempts futile
> > in first place ? If not, should I open an obolib issue on this ?
> > Anything else I could check ?
> >
> > Thanks in advance,
> > yours,
> > Steffen
> >
> > sneumann@acryl:~/src/oboformat-read-only/bin$ ./obolib-owl2obo 
> > /home/sneumann/nmrML/code/ontologies/nmrCV.owl  -o /tmp/nmrCV.obo
> > CMDARGS= /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o 
> > /tmp/nmrCV.obo
> > /usr/bin/java -d64 -Xmx2048M -Xms2048M -DentityExpansionLimit=512000 
> > -DlauncherDir=. -jar ./oboformat-all.jar --owl2obo 
> > /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o /tmp/nmrCV.obo
> > 2015-03-04 15:47:26,368 INFO  (OBORunner:159) saving to /tmp/nmrCV.obo
> > Exception in thread "main" 
> > org.obolibrary.oboformat.model.FrameStructureException: multiple 
> > is_obsolete tags not allowed. in frame:Frame(null import( 
> > http://purl.obolibrary.org/obo/bfo.owl{})ontology( 
> > http://nmrML.org/nmrCV{})created_by( Daniel Schober{})property_value( 
> > http://purl.org/dc/elements/1.1/contributor Since this is a prolonged 
> > effort spanning a larger time period, there naturally were many people 
> > involved in the creation over the years and during different times.
> >
> > People involved in the term creation from ID >1400000 :
> >
> > This part of the  NMR ontology was originally developed by the 
> > ontology working group (http://msi-ontology.sourceforge.net/) of the 
> > msi-metabolomicssociety (msi-workgroups.sf.net):
> >
> > Daniel Schober (EBI)
> > Chris Taylor (EBI and HUPO-PSI)
> > Dennis Rubtsov (Un of Cambridge, UK)
> > Helen Jenkins (Un of Wales, Aberystwyth, UK)
> > Irena Spasic (Center for Integrative Systems Biology, Manchester, UK)
> > Larissa Soldatova (University of Wales, Aberystwyth, UK)
> > Philippe Rocca-Serra (EBI and MGED Society)
> > Susanna-Assunta Sansone (EBI)
> >
> > People involved in the term creation from ID<1400000:
> >
> > Joseph Cruz
> > Michael Wilson
> > David Wishard
> >
> > Terms with IDs  ID<1400000 that were NOT asserted in the original 
> > Wishard obo file were created by Daniel Schober (COSMOS WP2). Its IDs 
> > were autogenerated with the Protege ID generator.
> >
> > Other people that substantially helped in revising the latest and 
> > Cosmos governed CV additions were:
> >
> > Michael Wilson, Wishard Group, Edmonton, Alberta, Canada
> > Daniel Jacobs, INRA, Bordeaux, France
> > Reza Salek, EBI, Hinxton, UK
> > Philippe Rocca-Serra, University of Oxford, Oxford, UK
> > Andrea Porzel, IPB-Halle, Germany
> > and the COSMOS WP2 team xsd:string{})property_value( 
> > http://purl.org/dc/elements/1.1/coverage Nuclear magnetic resonance 
> > (NMR) data annotation as required by the nmrML developed by the COSMOS 
> > EU project. xsd:string{})property_value( maintainer 
> > http://www.cosmos-fp7.eu/WP2 xsd:string{})format-version( 1.2{})def( 
> > This artefact is an MSI approved controlled vocabulary developed under 
> > COSMOS WP2 governance. This CV was derived from two predecessors (The 
> > NMR CV from the David Wishard Group, developed by Joseph Cruz) and the 
> > MSI nmr CV developed by Daniel Schober at the EBI.
> > This simple taxonomy of terms (no DL semantics used, for a short 
> > overview on the differences of Cv, taxonomy and ontology look at 
> > http://infogrid.org/trac/wiki/Reference/PidcockArticle) serves the 
> > nuclear magnetic resonance markup language (nmrML) with meaningful 
> > descriptors to amend the nmrML xml. Metabolomics scientists are 
> > encouraged to use this CV to annotrate their raw and experimental 
> > context data. The approach to have an exchange syntax mixed of an xsd 
> > and CV stems from the PSI mzML effort. The reason to branch out from 
> > an xsd into a CV is, that in areas where the terminology is likely to 
> > change faster than the nmrML xsd could be updated and aligned, an 
> > externally and possably decentrallised maintained CV can accompensate 
> > for such dynamics in a more flexible way. A second reason for this 
> > set-up is that semantic validity of CV terms used in a valid nmrML XML 
> > instance (allowed CV terms, position/relation to each other, 
> > cardinality) can be validated by rule-based proprietary validators:
> > By means of cardinality specifications and XPath expressions defined 
> > in an XML mapping file (an instances of the CvMappingRules.xsd ), one 
> > can define what ontology terms are allowed in a specific location of 
> > the data model.{})auto-generated-by( OBO-Edit 2.2{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400032 
> > xsd:string{})property_value( defaultLanguage en 
> > xsd:string{})property_value( http://purl.org/dc/elements/1.1/title 
> > nuclear magnetic resonance CV xsd:string{})is_obsolete( 
> > http://www.metabolomicscentre.ca/nmrML/msi-nmr.obo{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400073 
> > xsd:string{})property_value( owl:versionInfo 1.0.0 xsd:string{})xref( 
> > In case we like to be able to convert this owl CV back into the obo 
> > format, we should only use DL/owl constructs that are supported by 
> > obo. Hence, editors of this CV should take care not to use any higher 
> > descriptrion logics semantics, i.e. cardinality restrictions or 
> > defined terms using constructors. We should start to build the 
> > taxonomic backbone first and later connect the main axis via 
> > relations.
> > If we want to use restrictions, we should only use existential 
> > quantifiers as the OBO format does not support universal 
> > quantification.
> >
> > List of terms required by current XSD (August 2013): these were 
> > bookmarked in CV (annotation property) and are visible in the new 
> > nmrTab:
> >
> > CVTerm occurrences:
> > buffer-->buffer
> > solvent-->solvent
> > concentration standard type-->calibration compound , what is chemical 
> > shift reference ?  What calibration_reference_shift under calibration 
> > compound ?
> > concentration standard name	we here see a use-mention problem arising 
> > for the CV. The xsd should probably change here to avoid this.
> > encoding method (Quadrature detection method)	is this the same as 
> > encoding method ?
> > sample container-->NMR_sample_holder
> > (spectrum) y axis type-->coordinate system descriptor
> > post acquisition solvent suppression method	Two usages in xsd, but 
> > with differrent type ?  -->solvent suppression method
> > calibration compound	Two usages in xsd, but with differrent type 
> > ?-->calibration compound
> > data transformation method-->data transformation method
> > (spectral) projection method-->projection method
> > spectral denoising method-->spectral denoising method
> > window function method-->window function method
> > baseline correction method-->baseline correction
> > sample type-->NMR sample
> >
> > CVParam occurrences:
> > file content-->data file content
> > software type-->software
> > source file type-->data file attribute (needs refactoring)
> > instrument configuration type-->instrument configuration
> > processing method type-->data processing method
> >
> > CVParamType occurrences:
> > chemical shift standard-->chemical shift standard
> > solvent suppression method-->solvent suppression method
> > encoding scheme (Quadrature detection method)-->encoding method
> > window function parameter-->window function parameter
> >
> > CVParamWithUnitType occurrences:
> > CVParamWithUnitType is currently not used in the xsd and dangling ! I 
> > assume ValueWithUnitType substitutes it ?
> >
> > UserParamType occurrences:
> > No CV terms needed
> >
> > ValueWithUnitType occurrences:
> > These will have to be used from the Unit ontology.{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400042 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1000013 xsd:string{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400068 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1002010 xsd:string{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1000524 xsd:string{})created_by( 
> > COSMOS consortium{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1400033 xsd:string{})property_value( 
> > bug-database 
> > https://github.com/nmrML/nmrML/issues?labels=enhancement&state=open
> > Please label your CV issues in the git 'CVenhancement' or add the 
> > "CV:" prefix into the subject line. For more general critisism and 
> > recommendations please use our nmrML email list. xsd:string{})remark( 
> > This version uses the Basic Formal Ontology (BFO) as its top level 
> > ontology. All previosous versions used the BiotopLight (btl2) bio 
> > upper level ontology. We might close the resulting semantic gap by 
> > using OBI and IAO as intermediate bridges later.{})property_value( 
> > implements https://github.com/nmrML/nmrML xsd:string{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400074 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1000014 xsd:string{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400043 
> > xsd:string{})property_value( mailing-list 
> > https://groups.google.com/forum/?hl=en#!forum/nmrml/join 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1000531 xsd:string{})property_value( 
> > http://purl.org/dc/elements/1.1/rights Creative Commons Public Domain 
> > Mark 1.0 xsd:string{})property_value( 
> > http://xmlns.com/foaf/0.1/homepage http://nmrml.org/cv/ 
> > xsd:string{})saved-by( dschober{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1400096 xsd:string{})is_obsolete( 
> > http://bioportal.bioontology.org/ontologies/1033{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400128 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1000011 xsd:string{})property_value( 
> > bookmark http://nmrML.org/nmrCV#NMR:1400075 
> > xsd:string{})property_value( bookmark 
> > http://nmrML.org/nmrCV#NMR:1400062 xsd:string{})property_value( 
> > location https://github.com/nmrML/nmrML/tree/master/ontologies 
> > xsd:string{})creation_date( 03.03.2015{})property_value( audience This 
> > CV is to be used by metabolomics researchers who apply the  nmrML xml 
> > to store their NMR experimental results(primarily raw data) and 
> > (limited) basic metadata. xsd:string{})property_value( 
> > http://purl.org/dc/elements/1.1/format Rather flat CV in OWL syntax. 
> > Taxonomic backbone with few relations used. No OWL DL complexity such 
> > as cardinalities, blank nodes, nested class definitions. The Semantic 
> > Validator used an OBO converted file format due to historic reasons. 
> > The OBO file is auto-generated-by the OWL API (version 3.4.2). 
> > xsd:string{})property_value( documenter Daniel Schober 
> > xsd:string{})owl-axioms( Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
> > Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
> > Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
> > Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
> > Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
> >
> >
> > Ontology(
> > AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> 
> > "")
> > ){}))
> > 	at 
> > org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
> > 	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
> > 	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
> > 	at 
> > org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
> > 	at 
> > org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
> > 	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
> > 	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)
> >
> >
> >
> >
> >
> > -- 
> > IPB Halle                    AG Massenspektrometrie & Bioinformatik
> > Dr. Steffen Neumann          http://www.IPB-Halle.DE
> > Weinberg 3                   http://msbi.bic-gh.de
> > 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
> >                                +49 (0) 345 5582 - 0
> > sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website, 
> > sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub 
> > for all
> > things parallel software development, from weekly thought leadership 
> > blogs to
> > news, videos, case studies, tutorials and more. Take a look and join 
> > the
> > conversation now. 
> > http://goparallel.sourceforge.net/_______________________________________________
> > Obo-format mailing list
> > Obo...@li...
> > https://lists.sourceforge.net/lists/listinfo/obo-format


-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [Obo-format] Problem converting from OWL to OBO

[Chris M. <cjm...@lb...>]

Try

     owltools nmrCV.owl -o -f obo --no-check nmrCV.obo

You'll need https://github.com/owlcollab/owltools

But as a general rule an owl file in the wild will need massaging to get 
into something usable. The obo spec is a superset of what legacy tools 
typically expect and I assume the obo conversion is for a legacy tool

On 4 Mar 2015, at 7:37, Steffen Neumann wrote:

> Dear all,
>
> In the EU project http://www.cosmos-fp7.eu/
> we're developing a controlled vocabular / ontology
> http://nmrml.org/cv/ for use in metabolomics / NMR.
>
> The current nmrCV ontology is located at
> https://github.com/nmrML/nmrML/blob/master/ontologies/nmrCV.owl
>
> Since we are using tools from the http://open-ms.sourceforge.net/
> team, we need to convert the nmrCV.owl into the OBO format nmrCV.obo.
> Generally, this should work, as we do not use
> and concepts from OWL which are not available in OBO.
>
> We have done the conversion successfully through the export in 
> Protege,
> but since we need this in an automated manner, Philippe Rocca-Serra
> recommended in 
> https://github.com/nmrML/nmrML/issues/42#issuecomment-25201303
> to use obolib-owl2obo.
>
> However, I get some weird exceptions 
> https://github.com/nmrML/nmrML/issues/43
> which I am unable to interpret. This happened with both the obolib SVN
> back in September 2013, and with the version updated today:
>
> I use: ./obolib-owl2obo nmrCV.owl -o /tmp/nmrCV.obo
> and get
>
> Exception in thread "main" 
> org.obolibrary.oboformat.model.FrameStructureException:
> 	multiple is_obsolete tags not allowed. in frame:Frame(null ontology(
>      ....
>      [and then a whole lot of metadata from our ontology]
>      ....
> Ontology(
> AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> 
> "")
> ){}))
> 	at 
> org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
> 	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
> 	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
> 	at 
> org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
> 	at 
> org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
> 	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
> 	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)
>
> The full trace is below. My question:
>
> => How do I debug / find out *where* these "multiple is_obsolete tags"
> come from ? I don't see them in
> 	sneumann@acryl:~/nmrML/code/ontologies (master)$ grep is_obsolete 
> nmrCV.owl
> 	sneumann@acryl:~/nmrML/code/ontologies (master)$
> I am also not aware that we actually import any other resource,
> in my local copy of nmrCV.owl I have commented out the only import we 
> have:
> 	<!-- <owl:imports rdf:resource="&obo;bfo.owl"/> -->
>
>
> Or did I miss some constraints, which would make my attempts futile
> in first place ? If not, should I open an obolib issue on this ?
> Anything else I could check ?
>
> Thanks in advance,
> yours,
> Steffen
>
> sneumann@acryl:~/src/oboformat-read-only/bin$ ./obolib-owl2obo 
> /home/sneumann/nmrML/code/ontologies/nmrCV.owl  -o /tmp/nmrCV.obo
> CMDARGS= /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o 
> /tmp/nmrCV.obo
> /usr/bin/java -d64 -Xmx2048M -Xms2048M -DentityExpansionLimit=512000 
> -DlauncherDir=. -jar ./oboformat-all.jar --owl2obo 
> /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o /tmp/nmrCV.obo
> 2015-03-04 15:47:26,368 INFO  (OBORunner:159) saving to /tmp/nmrCV.obo
> Exception in thread "main" 
> org.obolibrary.oboformat.model.FrameStructureException: multiple 
> is_obsolete tags not allowed. in frame:Frame(null import( 
> http://purl.obolibrary.org/obo/bfo.owl{})ontology( 
> http://nmrML.org/nmrCV{})created_by( Daniel Schober{})property_value( 
> http://purl.org/dc/elements/1.1/contributor Since this is a prolonged 
> effort spanning a larger time period, there naturally were many people 
> involved in the creation over the years and during different times.
>
> People involved in the term creation from ID >1400000 :
>
> This part of the  NMR ontology was originally developed by the 
> ontology working group (http://msi-ontology.sourceforge.net/) of the 
> msi-metabolomicssociety (msi-workgroups.sf.net):
>
> Daniel Schober (EBI)
> Chris Taylor (EBI and HUPO-PSI)
> Dennis Rubtsov (Un of Cambridge, UK)
> Helen Jenkins (Un of Wales, Aberystwyth, UK)
> Irena Spasic (Center for Integrative Systems Biology, Manchester, UK)
> Larissa Soldatova (University of Wales, Aberystwyth, UK)
> Philippe Rocca-Serra (EBI and MGED Society)
> Susanna-Assunta Sansone (EBI)
>
> People involved in the term creation from ID<1400000:
>
> Joseph Cruz
> Michael Wilson
> David Wishard
>
> Terms with IDs  ID<1400000 that were NOT asserted in the original 
> Wishard obo file were created by Daniel Schober (COSMOS WP2). Its IDs 
> were autogenerated with the Protege ID generator.
>
> Other people that substantially helped in revising the latest and 
> Cosmos governed CV additions were:
>
> Michael Wilson, Wishard Group, Edmonton, Alberta, Canada
> Daniel Jacobs, INRA, Bordeaux, France
> Reza Salek, EBI, Hinxton, UK
> Philippe Rocca-Serra, University of Oxford, Oxford, UK
> Andrea Porzel, IPB-Halle, Germany
> and the COSMOS WP2 team xsd:string{})property_value( 
> http://purl.org/dc/elements/1.1/coverage Nuclear magnetic resonance 
> (NMR) data annotation as required by the nmrML developed by the COSMOS 
> EU project. xsd:string{})property_value( maintainer 
> http://www.cosmos-fp7.eu/WP2 xsd:string{})format-version( 1.2{})def( 
> This artefact is an MSI approved controlled vocabulary developed under 
> COSMOS WP2 governance. This CV was derived from two predecessors (The 
> NMR CV from the David Wishard Group, developed by Joseph Cruz) and the 
> MSI nmr CV developed by Daniel Schober at the EBI.
> This simple taxonomy of terms (no DL semantics used, for a short 
> overview on the differences of Cv, taxonomy and ontology look at 
> http://infogrid.org/trac/wiki/Reference/PidcockArticle) serves the 
> nuclear magnetic resonance markup language (nmrML) with meaningful 
> descriptors to amend the nmrML xml. Metabolomics scientists are 
> encouraged to use this CV to annotrate their raw and experimental 
> context data. The approach to have an exchange syntax mixed of an xsd 
> and CV stems from the PSI mzML effort. The reason to branch out from 
> an xsd into a CV is, that in areas where the terminology is likely to 
> change faster than the nmrML xsd could be updated and aligned, an 
> externally and possably decentrallised maintained CV can accompensate 
> for such dynamics in a more flexible way. A second reason for this 
> set-up is that semantic validity of CV terms used in a valid nmrML XML 
> instance (allowed CV terms, position/relation to each other, 
> cardinality) can be validated by rule-based proprietary validators:
> By means of cardinality specifications and XPath expressions defined 
> in an XML mapping file (an instances of the CvMappingRules.xsd ), one 
> can define what ontology terms are allowed in a specific location of 
> the data model.{})auto-generated-by( OBO-Edit 2.2{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400032 
> xsd:string{})property_value( defaultLanguage en 
> xsd:string{})property_value( http://purl.org/dc/elements/1.1/title 
> nuclear magnetic resonance CV xsd:string{})is_obsolete( 
> http://www.metabolomicscentre.ca/nmrML/msi-nmr.obo{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400073 
> xsd:string{})property_value( owl:versionInfo 1.0.0 xsd:string{})xref( 
> In case we like to be able to convert this owl CV back into the obo 
> format, we should only use DL/owl constructs that are supported by 
> obo. Hence, editors of this CV should take care not to use any higher 
> descriptrion logics semantics, i.e. cardinality restrictions or 
> defined terms using constructors. We should start to build the 
> taxonomic backbone first and later connect the main axis via 
> relations.
> If we want to use restrictions, we should only use existential 
> quantifiers as the OBO format does not support universal 
> quantification.
>
> List of terms required by current XSD (August 2013): these were 
> bookmarked in CV (annotation property) and are visible in the new 
> nmrTab:
>
> CVTerm occurrences:
> buffer-->buffer
> solvent-->solvent
> concentration standard type-->calibration compound , what is chemical 
> shift reference ?  What calibration_reference_shift under calibration 
> compound ?
> concentration standard name	we here see a use-mention problem arising 
> for the CV. The xsd should probably change here to avoid this.
> encoding method (Quadrature detection method)	is this the same as 
> encoding method ?
> sample container-->NMR_sample_holder
> (spectrum) y axis type-->coordinate system descriptor
> post acquisition solvent suppression method	Two usages in xsd, but 
> with differrent type ?  -->solvent suppression method
> calibration compound	Two usages in xsd, but with differrent type 
> ?-->calibration compound
> data transformation method-->data transformation method
> (spectral) projection method-->projection method
> spectral denoising method-->spectral denoising method
> window function method-->window function method
> baseline correction method-->baseline correction
> sample type-->NMR sample
>
> CVParam occurrences:
> file content-->data file content
> software type-->software
> source file type-->data file attribute (needs refactoring)
> instrument configuration type-->instrument configuration
> processing method type-->data processing method
>
> CVParamType occurrences:
> chemical shift standard-->chemical shift standard
> solvent suppression method-->solvent suppression method
> encoding scheme (Quadrature detection method)-->encoding method
> window function parameter-->window function parameter
>
> CVParamWithUnitType occurrences:
> CVParamWithUnitType is currently not used in the xsd and dangling ! I 
> assume ValueWithUnitType substitutes it ?
>
> UserParamType occurrences:
> No CV terms needed
>
> ValueWithUnitType occurrences:
> These will have to be used from the Unit ontology.{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400042 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1000013 xsd:string{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400068 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1002010 xsd:string{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1000524 xsd:string{})created_by( 
> COSMOS consortium{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1400033 xsd:string{})property_value( 
> bug-database 
> https://github.com/nmrML/nmrML/issues?labels=enhancement&state=open
> Please label your CV issues in the git 'CVenhancement' or add the 
> "CV:" prefix into the subject line. For more general critisism and 
> recommendations please use our nmrML email list. xsd:string{})remark( 
> This version uses the Basic Formal Ontology (BFO) as its top level 
> ontology. All previosous versions used the BiotopLight (btl2) bio 
> upper level ontology. We might close the resulting semantic gap by 
> using OBI and IAO as intermediate bridges later.{})property_value( 
> implements https://github.com/nmrML/nmrML xsd:string{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400074 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1000014 xsd:string{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400043 
> xsd:string{})property_value( mailing-list 
> https://groups.google.com/forum/?hl=en#!forum/nmrml/join 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1000531 xsd:string{})property_value( 
> http://purl.org/dc/elements/1.1/rights Creative Commons Public Domain 
> Mark 1.0 xsd:string{})property_value( 
> http://xmlns.com/foaf/0.1/homepage http://nmrml.org/cv/ 
> xsd:string{})saved-by( dschober{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1400096 xsd:string{})is_obsolete( 
> http://bioportal.bioontology.org/ontologies/1033{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400128 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1000011 xsd:string{})property_value( 
> bookmark http://nmrML.org/nmrCV#NMR:1400075 
> xsd:string{})property_value( bookmark 
> http://nmrML.org/nmrCV#NMR:1400062 xsd:string{})property_value( 
> location https://github.com/nmrML/nmrML/tree/master/ontologies 
> xsd:string{})creation_date( 03.03.2015{})property_value( audience This 
> CV is to be used by metabolomics researchers who apply the  nmrML xml 
> to store their NMR experimental results(primarily raw data) and 
> (limited) basic metadata. xsd:string{})property_value( 
> http://purl.org/dc/elements/1.1/format Rather flat CV in OWL syntax. 
> Taxonomic backbone with few relations used. No OWL DL complexity such 
> as cardinalities, blank nodes, nested class definitions. The Semantic 
> Validator used an OBO converted file format due to historic reasons. 
> The OBO file is auto-generated-by the OWL API (version 3.4.2). 
> xsd:string{})property_value( documenter Daniel Schober 
> xsd:string{})owl-axioms( Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
> Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
> Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
> Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
> Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
>
>
> Ontology(
> AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> 
> "")
> ){}))
> 	at 
> org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
> 	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
> 	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
> 	at 
> org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
> 	at 
> org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
> 	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
> 	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)
>
>
>
>
>
> -- 
> IPB Halle                    AG Massenspektrometrie & Bioinformatik
> Dr. Steffen Neumann          http://www.IPB-Halle.DE
> Weinberg 3                   http://msbi.bic-gh.de
> 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
>                                +49 (0) 345 5582 - 0
> sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, 
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub 
> for all
> things parallel software development, from weekly thought leadership 
> blogs to
> news, videos, case studies, tutorials and more. Take a look and join 
> the
> conversation now. 
> http://goparallel.sourceforge.net/_______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format

[Obo-format] Problem converting from OWL to OBO

[Steffen N. <sne...@ip...>]

Dear all,

In the EU project http://www.cosmos-fp7.eu/
we're developing a controlled vocabular / ontology 
http://nmrml.org/cv/ for use in metabolomics / NMR.

The current nmrCV ontology is located at 
https://github.com/nmrML/nmrML/blob/master/ontologies/nmrCV.owl

Since we are using tools from the http://open-ms.sourceforge.net/
team, we need to convert the nmrCV.owl into the OBO format nmrCV.obo.
Generally, this should work, as we do not use 
and concepts from OWL which are not available in OBO.

We have done the conversion successfully through the export in Protege,
but since we need this in an automated manner, Philippe Rocca-Serra 
recommended in https://github.com/nmrML/nmrML/issues/42#issuecomment-25201303
to use obolib-owl2obo. 

However, I get some weird exceptions https://github.com/nmrML/nmrML/issues/43
which I am unable to interpret. This happened with both the obolib SVN 
back in September 2013, and with the version updated today:

I use: ./obolib-owl2obo nmrCV.owl -o /tmp/nmrCV.obo
and get 

Exception in thread "main" org.obolibrary.oboformat.model.FrameStructureException: 
	multiple is_obsolete tags not allowed. in frame:Frame(null ontology(
        ....
        [and then a whole lot of metadata from our ontology]
        ....
Ontology(
AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> "")
){}))
	at org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
	at org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
	at org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)

The full trace is below. My question:

=> How do I debug / find out *where* these "multiple is_obsolete tags"
   come from ? I don't see them in 
	sneumann@acryl:~/nmrML/code/ontologies (master)$ grep is_obsolete nmrCV.owl
	sneumann@acryl:~/nmrML/code/ontologies (master)$ 
   I am also not aware that we actually import any other resource, 
   in my local copy of nmrCV.owl I have commented out the only import we have:
	<!-- <owl:imports rdf:resource="&obo;bfo.owl"/> -->

   
Or did I miss some constraints, which would make my attempts futile 
in first place ? If not, should I open an obolib issue on this ?
Anything else I could check ?

Thanks in advance,
yours,
Steffen

sneumann@acryl:~/src/oboformat-read-only/bin$ ./obolib-owl2obo /home/sneumann/nmrML/code/ontologies/nmrCV.owl  -o /tmp/nmrCV.obo
CMDARGS= /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o /tmp/nmrCV.obo
/usr/bin/java -d64 -Xmx2048M -Xms2048M -DentityExpansionLimit=512000 -DlauncherDir=. -jar ./oboformat-all.jar --owl2obo /home/sneumann/nmrML/code/ontologies/nmrCV.owl -o /tmp/nmrCV.obo
2015-03-04 15:47:26,368 INFO  (OBORunner:159) saving to /tmp/nmrCV.obo
Exception in thread "main" org.obolibrary.oboformat.model.FrameStructureException: multiple is_obsolete tags not allowed. in frame:Frame(null import( http://purl.obolibrary.org/obo/bfo.owl{})ontology( http://nmrML.org/nmrCV{})created_by( Daniel Schober{})property_value( http://purl.org/dc/elements/1.1/contributor Since this is a prolonged effort spanning a larger time period, there naturally were many people involved in the creation over the years and during different times.

People involved in the term creation from ID >1400000 :

This part of the  NMR ontology was originally developed by the ontology working group (http://msi-ontology.sourceforge.net/) of the msi-metabolomicssociety (msi-workgroups.sf.net):

Daniel Schober (EBI)
Chris Taylor (EBI and HUPO-PSI)
Dennis Rubtsov (Un of Cambridge, UK)
Helen Jenkins (Un of Wales, Aberystwyth, UK)
Irena Spasic (Center for Integrative Systems Biology, Manchester, UK)
Larissa Soldatova (University of Wales, Aberystwyth, UK)
Philippe Rocca-Serra (EBI and MGED Society)
Susanna-Assunta Sansone (EBI)

People involved in the term creation from ID<1400000:

Joseph Cruz
Michael Wilson
David Wishard

Terms with IDs  ID<1400000 that were NOT asserted in the original Wishard obo file were created by Daniel Schober (COSMOS WP2). Its IDs were autogenerated with the Protege ID generator. 

Other people that substantially helped in revising the latest and Cosmos governed CV additions were:

Michael Wilson, Wishard Group, Edmonton, Alberta, Canada
Daniel Jacobs, INRA, Bordeaux, France
Reza Salek, EBI, Hinxton, UK
Philippe Rocca-Serra, University of Oxford, Oxford, UK
Andrea Porzel, IPB-Halle, Germany
and the COSMOS WP2 team xsd:string{})property_value( http://purl.org/dc/elements/1.1/coverage Nuclear magnetic resonance (NMR) data annotation as required by the nmrML developed by the COSMOS EU project. xsd:string{})property_value( maintainer http://www.cosmos-fp7.eu/WP2 xsd:string{})format-version( 1.2{})def( This artefact is an MSI approved controlled vocabulary developed under COSMOS WP2 governance. This CV was derived from two predecessors (The NMR CV from the David Wishard Group, developed by Joseph Cruz) and the MSI nmr CV developed by Daniel Schober at the EBI.
 This simple taxonomy of terms (no DL semantics used, for a short overview on the differences of Cv, taxonomy and ontology look at http://infogrid.org/trac/wiki/Reference/PidcockArticle) serves the nuclear magnetic resonance markup language (nmrML) with meaningful descriptors to amend the nmrML xml. Metabolomics scientists are encouraged to use this CV to annotrate their raw and experimental context data. The approach to have an exchange syntax mixed of an xsd and CV stems from the PSI mzML effort. The reason to branch out from an xsd into a CV is, that in areas where the terminology is likely to change faster than the nmrML xsd could be updated and aligned, an externally and possably decentrallised maintained CV can accompensate for such dynamics in a more flexible way. A second reason for this set-up is that semantic validity of CV terms used in a valid nmrML XML instance (allowed CV terms, position/relation to each other, cardinality) can be validated by rule-based proprietary validators:
 By means of cardinality specifications and XPath expressions defined in an XML mapping file (an instances of the CvMappingRules.xsd ), one can define what ontology terms are allowed in a specific location of the data model.{})auto-generated-by( OBO-Edit 2.2{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400032 xsd:string{})property_value( defaultLanguage en xsd:string{})property_value( http://purl.org/dc/elements/1.1/title nuclear magnetic resonance CV xsd:string{})is_obsolete( http://www.metabolomicscentre.ca/nmrML/msi-nmr.obo{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400073 xsd:string{})property_value( owl:versionInfo 1.0.0 xsd:string{})xref( In case we like to be able to convert this owl CV back into the obo format, we should only use DL/owl constructs that are supported by obo. Hence, editors of this CV should take care not to use any higher descriptrion logics semantics, i.e. cardinality restrictions or defined terms using constructors. We should start to build the taxonomic backbone first and later connect the main axis via relations. 
If we want to use restrictions, we should only use existential quantifiers as the OBO format does not support universal quantification.

List of terms required by current XSD (August 2013): these were bookmarked in CV (annotation property) and are visible in the new nmrTab:

CVTerm occurrences:
buffer-->buffer
solvent-->solvent
concentration standard type-->calibration compound , what is chemical shift reference ?  What calibration_reference_shift under calibration compound ?
concentration standard name	we here see a use-mention problem arising for the CV. The xsd should probably change here to avoid this.
encoding method (Quadrature detection method)	is this the same as encoding method ?
sample container-->NMR_sample_holder
(spectrum) y axis type-->coordinate system descriptor
post acquisition solvent suppression method	Two usages in xsd, but with differrent type ?  -->solvent suppression method
calibration compound	Two usages in xsd, but with differrent type ?-->calibration compound
data transformation method-->data transformation method
(spectral) projection method-->projection method
spectral denoising method-->spectral denoising method
window function method-->window function method
baseline correction method-->baseline correction
sample type-->NMR sample

CVParam occurrences:
file content-->data file content
software type-->software
source file type-->data file attribute (needs refactoring)
instrument configuration type-->instrument configuration
processing method type-->data processing method

CVParamType occurrences:
chemical shift standard-->chemical shift standard
solvent suppression method-->solvent suppression method
encoding scheme (Quadrature detection method)-->encoding method
window function parameter-->window function parameter

CVParamWithUnitType occurrences:
CVParamWithUnitType is currently not used in the xsd and dangling ! I assume ValueWithUnitType substitutes it ?

UserParamType occurrences:
No CV terms needed

ValueWithUnitType occurrences:
These will have to be used from the Unit ontology.{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400042 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1000013 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400068 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1002010 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1000524 xsd:string{})created_by( COSMOS consortium{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400033 xsd:string{})property_value( bug-database https://github.com/nmrML/nmrML/issues?labels=enhancement&state=open
Please label your CV issues in the git 'CVenhancement' or add the "CV:" prefix into the subject line. For more general critisism and recommendations please use our nmrML email list. xsd:string{})remark( This version uses the Basic Formal Ontology (BFO) as its top level ontology. All previosous versions used the BiotopLight (btl2) bio upper level ontology. We might close the resulting semantic gap by using OBI and IAO as intermediate bridges later.{})property_value( implements https://github.com/nmrML/nmrML xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400074 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1000014 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400043 xsd:string{})property_value( mailing-list https://groups.google.com/forum/?hl=en#!forum/nmrml/join xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1000531 xsd:string{})property_value( http://purl.org/dc/elements/1.1/rights Creative Commons Public Domain Mark 1.0 xsd:string{})property_value( http://xmlns.com/foaf/0.1/homepage http://nmrml.org/cv/ xsd:string{})saved-by( dschober{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400096 xsd:string{})is_obsolete( http://bioportal.bioontology.org/ontologies/1033{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400128 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1000011 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400075 xsd:string{})property_value( bookmark http://nmrML.org/nmrCV#NMR:1400062 xsd:string{})property_value( location https://github.com/nmrML/nmrML/tree/master/ontologies xsd:string{})creation_date( 03.03.2015{})property_value( audience This CV is to be used by metabolomics researchers who apply the  nmrML xml to store their NMR experimental results(primarily raw data) and (limited) basic metadata. xsd:string{})property_value( http://purl.org/dc/elements/1.1/format Rather flat CV in OWL syntax. Taxonomic backbone with few relations used. No OWL DL complexity such as cardinalities, blank nodes, nested class definitions. The Semantic Validator used an OBO converted file format due to historic reasons. The OBO file is auto-generated-by the OWL API (version 3.4.2). xsd:string{})property_value( documenter Daniel Schober xsd:string{})owl-axioms( Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)


Ontology(
AnnotationAssertion(rdfs:comment <http://nmrML.org/nmrCV#NMR:1000409> "")
){}))
	at org.obolibrary.oboformat.model.Frame.checkMaxOneCardinality(Frame.java:255)
	at org.obolibrary.oboformat.model.Frame.check(Frame.java:235)
	at org.obolibrary.oboformat.model.OBODoc.check(OBODoc.java:235)
	at org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:126)
	at org.obolibrary.oboformat.writer.OBOFormatWriter.write(OBOFormatWriter.java:120)
	at org.obolibrary.cli.OBORunner.runConversion(OBORunner.java:171)
	at org.obolibrary.cli.OBORunner.main(OBORunner.java:88)





-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [Obo-format] broken link: serializer conventions

[Chris M. <cjm...@lb...>]

Fixed, thanks.

On 7 Oct 2014, at 1:54, Erick Antezana wrote:

> I was looking at the branched, old page (
> http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html
> ).
>
> Anyway, the 'official' one (trunk) has the same issue:
>
> http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html
>
> cheers,
> Erick
>
> On 7 October 2014 09:24, Erick Antezana <eri...@gm...> 
> wrote:
>
>> Hi,
>>
>> the OBO spec (
>> http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html)
>> has a broken link:
>> 8.1.3 Tag Ordering
>>
>> See the serializer conventions
>> <http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5> in the 
>> OBO
>> format guide
>>
>> 'serializer conventions' points to :
>> http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5
>>
>> could you please fix it?
>>
>> cheers,
>> Erick
>>
>>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
> Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format

Re: [Obo-format] broken link: serializer conventions

[Erick A. <eri...@gm...>]

I was looking at the branched, old page (
http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html
).

Anyway, the 'official' one (trunk) has the same issue:

http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html

cheers,
Erick

On 7 October 2014 09:24, Erick Antezana <eri...@gm...> wrote:

> Hi,
>
> the OBO spec (
> http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html)
> has a broken link:
> 8.1.3 Tag Ordering
>
> See the serializer conventions
> <http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5> in the OBO
> format guide
>
> 'serializer conventions' points to :
> http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5
>
> could you please fix it?
>
> cheers,
> Erick
>
>

[Obo-format] broken link: serializer conventions

[Erick A. <eri...@gm...>]

Hi,

the OBO spec (
http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html)
has a broken link:
8.1.3 Tag Ordering

See the serializer conventions
<http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5> in the OBO
format guide

'serializer conventions' points to :
http://www.geneontology.org/GO.format.obo-1_4.shtml#S.3.5

could you please fix it?

cheers,
Erick

[Obo-format] Some context: obo-format support in Protege and OWLAPI 3.5.x

[Chris M. <cjm...@lb...>]

Some context on the last email - a lot of discussion has happened on the 
owlapi list and trackers.

I'm pleased to belatedly report that the OWLAPI is using the main OBO 
Format parser from http://oboformat.org. To achieve this, Heiko and 
Ignazio refactored the code to be part of the OWLAPI. It can now be 
found here:

https://github.com/owlcs/owlapi/tree/master/oboformat

The command line wrapper is independent:
https://github.com/oboformat/oboformat-tools

This is in owlapi 3.5.x and above. This version of the owlapi is used in 
Protege 5.x. This means easy saving/reading from obo in Protege without 
an additional roundtrip step.

We will eventually switch owltools to use the owlapi v3.5.x, but this 
will be a seamless switch for users.

[Obo-format] Opinions? Skipping validation for writing obo-format documents

[Chris M. <cjm...@lb...>]

https://github.com/owlcs/owlapi/issues/290

In owltools, it's always been possible to skip validation with "-o -f 
obo --no-check my.obo", which is very useful if you need to defer fixing 
of issues. However, when using from Protege there is no equivalent of 
these options.

Re: [Obo-format] [go-discuss] Broken link: OBOF --> GO site

[Chris M. <cjm...@lb...>]

This is the URL for the OBO-Format guide:
http://oboformat.googlecode.com/svn/trunk/doc/GO.format.obo-1_4.html

For the historic versions:
http://oboformat.googlecode.com/svn/trunk/doc/GO.format.obo-1_2.html
http://oboformat.googlecode.com/svn/trunk/doc/GO.format.obo-1_0.html

I have fixed this on the oboformat.org front page

Note that the above links are non-normative guides to the specification.
The normative specification can be found on http://oboformat.org


On Fri, Aug 29, 2014 at 7:45 AM, <van...@ca...> wrote:

> Thanks, Erick.
>
> I'll submit a ticket to have someone take a look.
>
> Best,
> --Kimberly
>
>
>
> > Hi,
> >
> > yes, sorry I forgot to mention how I ended up there ;-)
> >
> > The URLs are:
> >
> >   ftp://ftp.geneontology.org/go/www/obo-syntax.html
> >
> >
> >
> http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html
> >
> > That's why I CC-ed the obo-format list too.
> >
> > cheers,
> > Erick
> >
> >
> >
> > On 29 August 2014 16:31, <van...@ca...> wrote:
> >
> >> Hi Erick,
> >>
> >> Thanks for reporting this.
> >>
> >> Can you send the URL of the page you're on where this broken link is?
> >>
> >> Best,
> >> --Kimberly Van Auken
> >> Database Curator, WormBase
> >>
> >>
> >>
> >> > Hi,
> >> >
> >> > There is a broken pointing to the old GO site:
> >> >
> >> > Abstract
> >> >
> >> > This document provides a BNF specification and mapping to OWL2 of the
> >> OBO
> >> > Flat File Format, version 1.4
> >> > <http://www.geneontology.org/GO.format.obo-1_4.shtml>
> >> >
> >> > cheers,
> >> > Erick
> >> > _______________________________________________
> >> > go-discuss mailing list
> >> > go-...@li...
> >> > https://mailman.stanford.edu/mailman/listinfo/go-discuss
> >> >
> >>
> >>
> >>
> >
>
>
> _______________________________________________
> go-discuss mailing list
> go-...@li...
> https://mailman.stanford.edu/mailman/listinfo/go-discuss
>
>

Re: [Obo-format] [go-discuss] Broken link: OBOF --> GO site

[Erick A. <eri...@gm...>]

Hi,

yes, sorry I forgot to mention how I ended up there ;-)

The URLs are:

  ftp://ftp.geneontology.org/go/www/obo-syntax.html


http://oboformat.googlecode.com/svn/branches/2011-11-29/doc/obo-syntax.html

That's why I CC-ed the obo-format list too.

cheers,
Erick



On 29 August 2014 16:31, <van...@ca...> wrote:

> Hi Erick,
>
> Thanks for reporting this.
>
> Can you send the URL of the page you're on where this broken link is?
>
> Best,
> --Kimberly Van Auken
> Database Curator, WormBase
>
>
>
> > Hi,
> >
> > There is a broken pointing to the old GO site:
> >
> > Abstract
> >
> > This document provides a BNF specification and mapping to OWL2 of the OBO
> > Flat File Format, version 1.4
> > <http://www.geneontology.org/GO.format.obo-1_4.shtml>
> >
> > cheers,
> > Erick
> > _______________________________________________
> > go-discuss mailing list
> > go-...@li...
> > https://mailman.stanford.edu/mailman/listinfo/go-discuss
> >
>
>
>

[Obo-format] Broken link: OBOF --> GO site

[Erick A. <eri...@gm...>]

Hi,

There is a broken pointing to the old GO site:

Abstract

This document provides a BNF specification and mapping to OWL2 of the OBO
Flat File Format, version 1.4
<http://www.geneontology.org/GO.format.obo-1_4.shtml>

cheers,
Erick

Re: [Obo-format] Fwd: [OWLAPI-developer] 3.4.9 release

[Ignazio P. <ipa...@gm...>]

Just a note for the subscribers of this list who are not also on the
OWLAPI mailing list: my integration of the new OBO parser in 3.4.9 is
not working properly, and an updated release will be made in the next
few days. I would recommend waiting before starting migrating code.

Cheers,
Ignazio

On 26 November 2013 16:50, Chris Mungall <cjm...@lb...> wrote:
>
>
> ---------- Forwarded message ----------
> From: Ignazio Palmisano <ipa...@gm...>
> Date: Mon, Nov 25, 2013 at 1:48 PM
> Subject: [OWLAPI-developer] 3.4.9 release
> To: owl...@li...
>
>
> This release will be available shortly on Maven Central and in the
> usual SourceForge folder.
>
> This release addresses a couple of minor issues with backwards
> compatibility and other minor features.
> It also replaces the OBO parser with the newer and better maintained parser
> at:
> https://code.google.com/p/oboformat/
>
> Cheers,
> Ignazio
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Owlapi-developer mailing list
> Owl...@li...
> https://lists.sourceforge.net/lists/listinfo/owlapi-developer
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format
>

[Obo-format] Fwd: [OWLAPI-developer] 3.4.9 release

[Chris M. <cjm...@lb...>]

---------- Forwarded message ----------
From: Ignazio Palmisano <ipa...@gm...>
Date: Mon, Nov 25, 2013 at 1:48 PM
Subject: [OWLAPI-developer] 3.4.9 release
To: owl...@li...


This release will be available shortly on Maven Central and in the
usual SourceForge folder.

This release addresses a couple of minor issues with backwards
compatibility and other minor features.
It also replaces the OBO parser with the newer and better maintained parser
at:
https://code.google.com/p/oboformat/

Cheers,
Ignazio

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Owlapi-developer mailing list
Owl...@li...
https://lists.sourceforge.net/lists/listinfo/owlapi-developer

[Obo-format] New non-normative section with recommendations for imports

[Chris M. <cjm...@lb...>]

http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#8.4

basic summary - you are strongly advised NOT to use import directives in
obo-format, they are not well supported. In cases where there is necessary
(the only case of this should be dependence on obo-edit) then you should
use OWL URIs and an oboedit.catalog file to map these. Stay tuned on the
obo-edit-wg mailing list for details of oboedit.catalog support in OE.

Re: [Obo-format] owl-axioms?

[Chris M. <cjm...@lb...>]

See
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#5.0.4

OE supports this in that it roundtrips the axioms.

CL: note that like many ontologies we provide a basic version:

http://purl.obolibrary.org/obo/cl/cl-basic.obo

Which has this removed.


On Thu, Oct 31, 2013 at 12:42 AM, Erick Antezana
<eri...@gm...>wrote:

> Hi,
>
> I have seen that the Cell Type ontology makes use of the following tag in
> its header:
>
>    owl-axioms: Prefix(owl:=...
>
> What's the purpose of this new tag? will it end up in the OBO spec at some
> point?
>
> I find that the particular example of the CL ontology introduces too much
> "noise" into the file ...
>
> Does OBO-Edit support it?
>
> cheers,
> Erick
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format
>
>

[Obo-format] owl-axioms?

[Erick A. <eri...@gm...>]

Hi,

I have seen that the Cell Type ontology makes use of the following tag in
its header:

   owl-axioms: Prefix(owl:=...

What's the purpose of this new tag? will it end up in the OBO spec at some
point?

I find that the particular example of the CL ontology introduces too much
"noise" into the file ...

Does OBO-Edit support it?

cheers,
Erick

Re: [Obo-format] oboformat Maven release and availability

[Chris M. <cjm...@lb...>]

The googlecode repo says new BSD, but we can license under the Apache if
that makes it easier for you (and add a LICENSE.txt)


On Mon, Oct 14, 2013 at 2:10 PM, Ignazio Palmisano <
ipa...@gm...> wrote:

> I have found the answer to this in the source: the maven repositories
> are listed in the pom file.
>
> Another related question: what is the intended license of the source code?
>
> In order to complete my task, i.e., seamlessly replacing the existing
> OWLAPI OBO parser, I need to make consistent changes to the structure
> of the module, splitting it in a part that depends only on the parsers
> module, and a part that relies on the rest of the OWLAPI, which mostly
> means all the classes and methods that use OWLManager.
> Since it might be necessary to redistribute the source together with
> the OWLAPI, I've been searching for license notices but did not find
> any.
> Can you tell me what are your preferences in this regard?
>
> Cheers,
> Ignazio
>
> On 11 October 2013 19:12, Ignazio Palmisano
> <ipa...@gm...> wrote:
> > Hi guys,
> > I'm in the process of integrating the obo format parser and renderer
> > with the OWL API and I'm wondering if there is a public Maven
> > repository where the latest release can be found - I could not find it
> > on Maven Central.
> >
> > Cheers,
> > I.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format
>

Re: [Obo-format] oboformat Maven release and availability

[Chris M. <cjm...@lb...>]

Fantastic, thank you, this is great news!

Heiko is in charge of our maven repo, he's on holiday for the next few
weeks, but you may be able to find everything you need here:
http://code.berkeleybop.org/maven/repository/org/bbop/oboformat/




On Fri, Oct 11, 2013 at 11:12 AM, Ignazio Palmisano <
ipa...@gm...> wrote:

> Hi guys,
> I'm in the process of integrating the obo format parser and renderer
> with the OWL API and I'm wondering if there is a public Maven
> repository where the latest release can be found - I could not find it
> on Maven Central.
>
> Cheers,
> I.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format
>

Re: [Obo-format] oboformat Maven release and availability

[Ignazio P. <ipa...@gm...>]

I have found the answer to this in the source: the maven repositories
are listed in the pom file.

Another related question: what is the intended license of the source code?

In order to complete my task, i.e., seamlessly replacing the existing
OWLAPI OBO parser, I need to make consistent changes to the structure
of the module, splitting it in a part that depends only on the parsers
module, and a part that relies on the rest of the OWLAPI, which mostly
means all the classes and methods that use OWLManager.
Since it might be necessary to redistribute the source together with
the OWLAPI, I've been searching for license notices but did not find
any.
Can you tell me what are your preferences in this regard?

Cheers,
Ignazio

On 11 October 2013 19:12, Ignazio Palmisano
<ipa...@gm...> wrote:
> Hi guys,
> I'm in the process of integrating the obo format parser and renderer
> with the OWL API and I'm wondering if there is a public Maven
> repository where the latest release can be found - I could not find it
> on Maven Central.
>
> Cheers,
> I.

[Obo-format] oboformat Maven release and availability

[Ignazio P. <ipa...@gm...>]

Hi guys,
I'm in the process of integrating the obo format parser and renderer
with the OWL API and I'm wondering if there is a public Maven
repository where the latest release can be found - I could not find it
on Maven Central.

Cheers,
I.

Re: [Obo-format] On the ugliness of IAO metadata properties in the OWL->OBO translation, and proposal to ameliorate this

[Chris M. <cjm...@lb...>]

On Feb 26, 2013, at 7:59 AM, Alan Ruttenberg wrote:

> Do I recall correctly that parsers are supposed to ignore tags they don't understand?

Your answer can be found here:
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#3.3

In obof1.4 it's not conformant if there's an unrecognized tag. The official parser will throw an error if it doesn't recognize a tag (and at the moment there's no way to override this).

Now the story is a bit more complex - in obof guides 1.2 and 1.0 the parser guidelines were to ignore unrecognized tags, as we wanted to make the parsers work with future extensions. We didn't know what was on the horizon.

In contrast we do know the future for obo-format now. The end. 1.4 should be the last version of obo-format. "obo format 2.0" is likely to be some extension of OWL manchester syntax or similar.

I had hoped we would be further on the path to transitioning ontology projects to OWL by this stage. Unfortunately the tools are not there yet, and version control in OWL is horrible after you're used to this in obo-format. This is slowly changing (see for example [1] [2])[3], but in the interim there is wiggle room in the spec for features editors critically need.

The story is different for software developers - new software should consume OWL (directly or via the obo2owl translation). Of course for legacy software it's always possible to translate back. I'm happy to talk with anyone and give recommendations for your own favorite language or environment.

> 
> If so, adding new tags would at least not hurt old parsers. 
> 
> I would be in favor of allowing arbitrary tag value pairs, if that's the case, ideally with a mechanism for adding metadata about them, e.g. Something like tagdef. 

A neat idea that should have been implemented way back, but to do this in a satisfactory way would probably end up breaking existing code (.e.g you'd probably want to introduce a new stanza type to define your extended syntax)

I'm not sure who would benefit from this. What's the scenario you have in mind?

I think Erick wants obo-format to be like perl, you want it to be like lisp, when in fact the reality is that it's more like COBOL :-(

> I don't see the goal of OBO as necessarily being full OWL 2 roundtripping.

Agreed.

> I'll try to write an explanation of why this is perhaps unnecessary, and if not what benefits relaxing this constrain might bring. Roughly we could define a pair of OWL and OBO files and merge operations from OBO into OWL and OWL into OBO for the subset of features that oboedit can comfortably handle. The. Editing could happen in either, with the OBO being in sync only over a subset of the expressivity. What you can't express easily in OBO you don't see in OBO, just in OWL. 

The roundtripping probably deserves another email...

Cheers
Chris

[1] http://wiki.geneontology.org/index.php/Ontology_editor_plugins
[2] http://lists.w3.org/Archives/Public/public-owled/2012Aug/thread.html#msg0
[3] http://www.russet.org.uk/blog/2040?
...and many more

> -Alan 
> 
> 
> On Monday, February 25, 2013, Chris Mungall wrote:
> 
> On Feb 25, 2013, at 5:50 PM, Alan Ruttenberg wrote:
> 
>> 
>> 
>> On Mon, Feb 25, 2013 at 5:35 PM, Erick Antezana <eri...@gm...> wrote:
>> I would think the owl2obo for that term should look like the following
>> (assuming that "alternative term"  (IAO) = exact synonym):
>> 
>> [Term]
>> id: BFO:0000004
>> name: independent continuant
>> def: "A continuant  that is a bearer of quality  and realizable entity
>>  entities, in which other entities inhere and which itself cannot
>> inhere in anything." []
>> property_value: example_of_usage "a chair" xsd:string
>> property_value: example_of_usage "a heart" xsd:string
>> property_value: example_of_usage "a leg" xsd:string
>> property_value: example_of_usage "a person" xsd:string
>> property_value: example_of_usage "a symphony orchestra" xsd:string
>> property_value: example_of_usage "an organism" xsd:string
>> property_value: example_of_usage "the bottom right portion of a human
>> torso" xsd:string
>> property_value: example_of_usage "the lawn and atmosphere in front of
>> our building" xsd:string
>> synonym: "substantial entity" EXACT []
>> is_a: BFO:0000002 ! continuant
>> 
>> Why the extra "property value:" and xsd:string noise?
>>  
>> 
>> or something like the following if we have extra instances or terms:
>> 
>> [Term]
>> id: BFO:0000004
>> name: independent continuant
>> def: "A continuant  that is a bearer of quality  and realizable entity
>>  entities, in which other entities inhere and which itself cannot
>> inhere in anything." []
>> property_value: example_of_usage chair
>> property_value: example_of_usage heart
>> property_value: example_of_usage leg
>> property_value: example_of_usage person
>> property_value: example_of_usage symphony_orchestra
>> property_value: example_of_usage organism
>> property_value: example_of_usage XYZ:0000011
>> property_value: example_of_usage XYZ:0000012
>> synonym: "substantial entity" EXACT []
>> is_a: BFO:0000002 ! continuant
>> 
>> where 'chair', 'heart', 'leg', ..., XYZ:0000011 (=the lawn...) are IDs
>> of an instance or term/universal...
>> 
>> I think that some terms will have other kind of example_of_usage's
>> where their type could be a date (xsd:date) or a positive integer
>> (xsd:positiveInteger)... if so, explicitly having xsd:string might
>> still be useful...
>> 
>> 
>> I agree that having type information is useful. But default the common case, which is xsd:string. Or better have some way to map strings to instances, so the mapping can be imported in different places. Or use the approach that manchester syntax does, which is that if it looks like a number it, it *is* a number. Could do the same with dates.
>> 
>> OWL can't do defaulting or dwimming, but OBO can. 
> 
> This would be a non-backwards compatible change. I'm hesitant to do this unless there's strong demand.
> 
>>  
>> 
>> cheers,
>> Erick
>> 
>> On 25 February 2013 05:26, Alan Ruttenberg <ala...@gm...> wrote:
>> > I was looking at an OORT generated OBO version of OBI and was struck by how
>> > unnecessarily (afaik) unpleasant rendering. Here's the example:
>> >
>> > Before:
>> >
>> > [Term]
>> > id: BFO:0000004
>> > name: independent continuant
>> > def: "A continuant  that is a bearer of quality  and realizable entity
>> > entities, in which other entities inhere and which itself cannot inhere in
>> > anything." []
>> > property_value: IAO:0000111 "independent continuant" xsd:string
>> > property_value: IAO:0000112 "a chair" xsd:string
>> > property_value: IAO:0000112 "a heart" xsd:string
>> > property_value: IAO:0000112 "a leg" xsd:string
>> > property_value: IAO:0000112 "a person" xsd:string
>> > property_value: IAO:0000112 "a symphony orchestra" xsd:string
>> > property_value: IAO:0000112 "an organism" xsd:string
>> > property_value: IAO:0000112 "the bottom right portion of a human torso"
>> > xsd:string
>> > property_value: IAO:0000112 "the lawn and atmosphere in front of our
>> > building" xsd:string
>> > property_value: IAO:0000118 "substantial entity" xsd:string
>> > is_a: BFO:0000002 ! continuant
>> >
>> > Here's  what I think it should look like. Comments below. Is there a reason
>> > it can't look like this? It seems that the benefit of OBO, something that we
>> > should retain, is that it's possible to read and author it in a text editor.
>> >
>> > [Term]
>> > id: BFO:0000004
>> > name: independent continuant
>> > def: "A continuant  that is a bearer of quality  and realizable entity
>> > entities, in which other entities inhere and which itself cannot inhere in
>> > anything." []
>> > example_of_usage: "a chair"
>> > example_of_usage: "a heart"
>> > example_of_usage: "a leg"
>> > example_of_usage: "a person"
>> > example_of_usage: "a symphony orchestra"
>> > example_of_usage: "an organism"
>> > example_of_usage: "the bottom right portion of a human torso"
>> > example_of_usage: "the lawn and atmosphere in front of our building"
>> > synonym: "substantial entity" EXACT
>> > is_a: BFO:0000002 ! continuant
>> >
>> > Notes:
>> > Don't repeat name as IAO:0000111 - they mean the same thing.
>> > IAO:0000118 'alternative term' means the same thing as exact synonym
>> > property_value: IAO:0000112 means example of usage. I use a tag that says
>> > that. Is there a reason that the generic tag is necessary/desirable in
>> > someone's view?
>> > One doesn't need to ever write xsd:string, since that's the only type of
>> > string there is. When there is provision for language tags that will merit
>> > some extra markup.
>> >
>> > While there may be some controversy on a small set of the IAO metadata tags,
>> > particularly non-exact "synonyms", most of the metadata terms we envisioned
>> > as fitting comfortably in OBO syntax. The other ones I would add as built-in
>> > tags are (perhaps not exclusively - but these make sense on quick glance)
>> >
>> > editor-note:
>> > curation-note:
>> > curation-status:
>> > term-editor:
>> > obsolescence-reason:
>> > imported-from:
>> > denotator-type:
>> > first-order-logic-expression:
>> >
>> > While the field values of some of these are supposed to be taken from
>> > enumerated sets (e.g. curation_status is (currently) one of {'example to be
>> > eventually removed' , 'metadata complete' , 'organizational term' , 'ready
>> > for release' , 'metadata incomplete' , uncurated , 'pending final vetting' ,
>> > 'to be replaced with external ontology term' , 'requires discussion'}
>> > there's no reason why the translation rules can't take these from strings to
>> > their instances.
>> >
>> > Some of these tags could be construed to be equivalent to properties in
>> > other vocabularies, e.g. 'alternative term' -> skos:altLabel. When there was
>> > a wider discussion of this issue a number of years ago, the thought was 1)
>> > The other vocabulary terms are often poorly defined or ambiguous 2) that we
>> > should have, at least, annotation properties that are defined how we want
>> > them to be 3) That we should, in those cases where we define
> 

Re: [Obo-format] On the ugliness of IAO metadata properties in the OWL->OBO translation, and proposal to ameliorate this

[Chris M. <cjm...@lb...>]

On Feb 26, 2013, at 2:37 AM, Erick Antezana wrote:

> On 25 February 2013 23:50, Alan Ruttenberg <ala...@gm...> wrote:
>> 
>> 
>> On Mon, Feb 25, 2013 at 5:35 PM, Erick Antezana <eri...@gm...>
>> wrote:
>>> 
>>> I would think the owl2obo for that term should look like the following
>>> (assuming that "alternative term"  (IAO) = exact synonym):
>>> 
>>> [Term]
>>> id: BFO:0000004
>>> name: independent continuant
>>> def: "A continuant  that is a bearer of quality  and realizable entity
>>> entities, in which other entities inhere and which itself cannot
>>> inhere in anything." []
>>> property_value: example_of_usage "a chair" xsd:string
>>> property_value: example_of_usage "a heart" xsd:string
>>> property_value: example_of_usage "a leg" xsd:string
>>> property_value: example_of_usage "a person" xsd:string
>>> property_value: example_of_usage "a symphony orchestra" xsd:string
>>> property_value: example_of_usage "an organism" xsd:string
>>> property_value: example_of_usage "the bottom right portion of a human
>>> torso" xsd:string
>>> property_value: example_of_usage "the lawn and atmosphere in front of
>>> our building" xsd:string
>>> synonym: "substantial entity" EXACT []
>>> is_a: BFO:0000002 ! continuant
>> 
>> 
>> Why the extra "property value:" and xsd:string noise?
> 
> I agree that "xsd:string" could be the default data type, thus
> reducing unnecessary stuff.. Regarding "property_value", I would
> prefer to have it as an indicator of a value associated to a given
> term so that the differenciantion between (pre-)defined OBO tags (e.g.
> name, relationship, synonym) and other "relationships:properties"
> (e.g. example_of_usage) be easier to read and parse.

Unfortunately this will introduce compatibility problems. Since 2005 there have been both 2 and 3 argument forms, corresponding to rdf objects and literals respectively. 

Syntax:
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#3.3

Translation:
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#5.6

Unfortunately this original design leads to problems with language literals. We may need to introduce some changes here in a way that doesn't break parsers (not that there are many native obo format ontologies that use these generic tags).

The most conservative change is to allow rdfs:Literal in the final argument, or opening this up further to other datatypes.

> 
>> 
>>> 
>>> 
>>> or something like the following if we have extra instances or terms:
>>> 
>>> [Term]
>>> id: BFO:0000004
>>> name: independent continuant
>>> def: "A continuant  that is a bearer of quality  and realizable entity
>>> entities, in which other entities inhere and which itself cannot
>>> inhere in anything." []
>>> property_value: example_of_usage chair
>>> property_value: example_of_usage heart
>>> property_value: example_of_usage leg
>>> property_value: example_of_usage person
>>> property_value: example_of_usage symphony_orchestra
>>> property_value: example_of_usage organism
>>> property_value: example_of_usage XYZ:0000011
>>> property_value: example_of_usage XYZ:0000012
>>> synonym: "substantial entity" EXACT []
>>> is_a: BFO:0000002 ! continuant
>>> 
>>> where 'chair', 'heart', 'leg', ..., XYZ:0000011 (=the lawn...) are IDs
>>> of an instance or term/universal...
>>> 
>>> I think that some terms will have other kind of example_of_usage's
>>> where their type could be a date (xsd:date) or a positive integer
>>> (xsd:positiveInteger)... if so, explicitly having xsd:string might
>>> still be useful...
>> 
>> 
>> 
>> I agree that having type information is useful. But default the common case,
>> which is xsd:string.

See above. The spec states that if no 3rd argument is present then it's an object and its translated according to different rules. All versions of oboedit in existence also assume this.

>> Or better have some way to map strings to instances, so
>> the mapping can be imported in different places. Or use the approach that
>> manchester syntax does, which is that if it looks like a number it, it *is*
>> a number. Could do the same with dates.
> 
> agree if the data follows strict formatting to be recognised by OBO
> parsers, for intance if the dates follow the ISO 8601 or any other
> "standard" that could be detected while parsing.

The grammar could get rather complex (in addition to breaking compatibility)

>> 
>> OWL can't do defaulting or dwimming, but OBO can.

I wouldn't pin your hopes on obo-format becoming the perl of ontology languages (well, maybe it already is)....

Re: [Obo-format] On the ugliness of IAO metadata properties in the OWL->OBO translation, and proposal to ameliorate this

[Chris M. <cjm...@lb...>]

On Feb 26, 2013, at 2:53 AM, Erick Antezana wrote:

> On 26 February 2013 00:31, Chris Mungall <cjm...@lb...> wrote:
>> 
>> 
>> 
>> On Feb 25, 2013, at 5:35 PM, Erick Antezana wrote:
>> 
>>> I would think the owl2obo for that term should look like the following
>>> (assuming that "alternative term"  (IAO) = exact synonym):
>>> 
>>> [Term]
>>> id: BFO:0000004
>>> name: independent continuant
>>> def: "A continuant  that is a bearer of quality  and realizable entity
>>> entities, in which other entities inhere and which itself cannot
>>> inhere in anything." []
>>> property_value: example_of_usage "a chair" xsd:string
>>> property_value: example_of_usage "a heart" xsd:string
>>> property_value: example_of_usage "a leg" xsd:string
>>> property_value: example_of_usage "a person" xsd:string
>>> property_value: example_of_usage "a symphony orchestra" xsd:string
>>> property_value: example_of_usage "an organism" xsd:string
>>> property_value: example_of_usage "the bottom right portion of a human
>> 
>> To do this either we have to hardcore the IAO label into the BNF, or we have to implement a complex translation rule involving a lookup to IAO and translating spaces to underscores.
>> 
>> Maybe I'm missing something, do you want to suggest specific changes to the spec?
> 
> no, I prefer to keep it as it is: support for generic property_value's
> (otherwise not only the spec/BNF needs to be updated but also OBO
> parsers). The OBO lines above (and below) are my interpretations of
> the OBO spec for that specific owl2obo translation.

The spec states that the ID form of the URI for the annotation property goes into the property_value field - hence IAO:nnnn rather than an underscore-separated label.

However, there is a "trick" in obo-format where you can specify a shorthand symbol in place of the property symbol. If you do this:

[Typedef]
id: my_internal_label
is_metadata: true
is_class_level: true
xref: IAO:nnnnnn

Then you can say

property_value: my_internal_label "...." xsd:string

But this isn't going to buy you much. For users such as yourself I would be focusing on the best W3 OWL syntax for your uses. Your tools all import OWL don't they?