Re: [Obo-format] [IAO] additions to support obo-format

[Melanie C. <mco...@gm...>]

I see;  thanks for the explanation. In the case of IAO few people are  
editing the file, and the addition of those properties is probably a  
one time event, so it may be less of an issue.

What about submitting your list to the IAO tracker at http://code.google.com/p/information-artifact-ontology/issues/list 
, and when ready you can decide or not to go ahead with the block of  
IDs? If I remember correctly the script we currently use to assign IDs  
doesn't allow for now to skip block of reserved IDs, so that would  
need to be added if required. Maybe Alan (who wrote the script) has  
more information about that and/or an indication of how easy it would  
be to add that feature.

Melanie


On 6-Jan-11, at 3:31 PM, Chris Mungall wrote:

>
> Purely to prevent clashes when we have multiple people editing  
> (which is frequent with GO, I notice that the ontologies you work on  
> have an email-based check in check out system, so perhaps less of a  
> priority for these).
>
> On Jan 6, 2011, at 2:58 PM, Melanie Courtot wrote:
>
>> Hi Chris,
>>
>> What is the difference between getting a block of IDs or getting a  
>> numerical ID when a term is added?
>> I am thinking that instead of blocking IAO_0002000 to IAO_0003000  
>> for example we could allocate IDs on a per demand basis as we add  
>> the properties (which could result in one being IAO_00000872 and  
>> another being IAO_00034562 for example)
>>
>> For the record I don't have any objection to blocking a set of ID,  
>> just wondering about the practical difference.
>>
>> Also I added a few notes inline on the proposal below.
>>
>> Thanks,
>> Melanie
>>
>>
>>
>> On 6-Jan-11, at 2:16 PM, Chris Mungall wrote:
>>
>>> Would it be possible to get a block of IAO ontology-metadata IDs  
>>> to add new annotation properties to support the obo-owl conversion?
>>>
>>> See table 5.8:
>>> http://berkeleybop.org/~cjm/obo2owl/obo-syntax.html#5
>>>
>>> consider        TBD
>>> synonym-scope   TBD
>>> synonym-type    TBD
>>> scope-EXACT     TBD
>>> scope-NARROW    TBD
>>> scope-BROAD     TBD
>>> scope-RELATED   TBD
>>> synonymtypedef  TBD
>>> xref    TBD
>>> subsetdef       TBD
>>> subset  TBD
>>> alt_id  TBD
>>>
>>> (also, it might be useful to have an AP for assigning a block of  
>>> numeric IDs to an ontology editor (GO currently represents this  
>>> outside the ontology))
>>>
>>> The goal here is to have a round-trippable representation of the  
>>> metadata in obo-format (which may not be optimal, but is set in  
>>> stone for backward compatibility reasons)
>>>
>>> proposed definitions and metadata:
>>>
>>> AnnotationProperty
>>> label: consider
>>> def: An annotation property that connects a deprecated information  
>>> artifact to an information artifact that can be used in its place
>>> comment: contrast with IAO_0100001 (replaced_by), which should  
>>> only be used when the replacement can be made automatically
>>> def_xref: http://wiki.geneontology.org/index.php/Curator_Guide:_Obsoletion#Alternatives_for_Obsolete_Terms 
>>> , http://www.geneontology.org/GO.format.obo-1_4.shtml
>>> xref: obo-format:consider
>>
>> we already have an annotation property "term replaced by", http://purl.obolibrary.org/obo/IAO_0100001 
>> , defined as "Use on obsolete terms, relating the term to another  
>> term that can be used as a substitute" Would that work for you?
>>
>>>
>>> AnnotationProperty
>>> label: xref
>>> def: an alternate information artefact that is either equivalent  
>>> to or closely equivalent to, where closely equivalent to is  
>>> informally defined as sharing a large number of instances, or  
>>> being closely related through some other property. stronger than  
>>> rdfs:seeAlso, because we could conceivable use rdfs:seeAlso for  
>>> antonyms etc.
>>> subannotationpropertyof: rdfs:seeAlso
>>> xref: obo-format:xref
>>>
>>> Class:
>>> label: ontology subset
>>> subclassof: information artifact
>>> def: a collection of classes that are grouped according to some  
>>> purpose. analagous to a metaclass, but avoids the overhead of  
>>> punning in owl
>>> xref: obo-format:subsetdef
>>
>>> AnnotationProperty
>>> label: member of ontology subset
>>> def: connects an information artefact to an ontology subset to  
>>> which it is a member of.
>>> comments: the range of this property should be individuals of the  
>>> class ontology subset (we cannot declare this for annotation  
>>> properties)
>>> xref: obo-format:subset
>>
>> We have been using http://www.geneontology.org/formats/oboInOwl#Subset 
>> , asserted under "data about an ontology part", and its instances  
>> to define the subsets (e.g. "core" was used at some point in OBI to  
>> identify our main classes) Similar to what has been done with  
>> "curation status" Would something like that be suitable for your  
>> use case?
>>
>>>
>>> Class
>>> label: alternate label category
>>> subclassof: information artifact
>>> def: an information artefact that can be used to connect usages of  
>>> labels of classes to contexts in which they are used
>>> example instances: abbreviation, scientific name
>>> xref: obo-format:synonymtypedef
>>>
>>> AnnotationProperty
>>> label: broad alternate label
>>> subannotationpropertyof: alternate label
>>> def: an alternate label for a class C that denotes something more  
>>> general than C
>>> xref: obo-format:BROAD
>>>
>>> AnnotationProperty
>>> label: exact alternate label
>>> subannotationpropertyof: alternate label
>>> def: an alternate label for a class C that precisely denotes C in  
>>> the context of the domain of the ontology in which it is used
>>> xref: obo-format:EXACT
>>
>> What is the difference with "alternative term", IAO_0000118  
>> (defined as "An alternative name for a class or property which  
>> means the same thing as the preferred name (semantically  
>> equivalent)")
>>>
>>>
>>> AnnotationProperty
>>> label: exact alternate label
>>> subannotationpropertyof: alternate label
>>> def: an alternate label for a class C that denotes something more  
>>> specific than C
>>> xref: obo-format:NARROW
>>
>> I guess it's a typo and the right label would be "narrow alternate  
>> label"?
>>
>> Do you have example of usages for broad and narrow alternate label  
>> showing how it is useful to capture that information? I would think  
>> that if users need something more general they would refer to a  
>> superclass, while if they need something more specific they would  
>> request creation of a subclass.
>>
>>>
>>> AnnotationProperty
>>> label: related alternate label
>>> subannotationpropertyof: alternate label
>>> def: an alternate label for a class C that denotes something that  
>>> is not precisely C, and is neither more general nor more specific  
>>> than C
>>> xref: obo-format:RELATED
>>
>> Do you have an example where using this is preferred over for  
>> example rdfs:seeAlso?
>>
>>>
>>> AnnotationProperty
>>> label: has alternate label category
>>> def: a property that links an alternate label annotation assertion  
>>> axiom to an individual of the class alternate label category.  
>>> Example: AnnotationAssertion( Annotation('has alternate label  
>>> category' iao:taxonomic name) 'alternate label' Taxon:1234  
>>> "wibblius wibblii")
>>> xref: obo-format:synonym-type
>>>
>>> AnnotationProperty
>>> label: alt_id
>>> def: when a class X is merged into a class Y, the original  
>>> identifier for X is retained as an alt_id.
>>> subannotationpropertyof: rdfs:seeAlso
>>>
>>> -- 
>>> inf...@go...
>>> To change settings, visit
>>> http://groups.google.com/group/information-ontology
>>
>> ---
>> Mélanie Courtot
>> MSFHR trainee, TFL- BCCRC
>> 675 West 10th Avenue
>> Vancouver, BC
>> V5Z 1L3, Canada
>>
>>
>>
>>
>>
>>
>