Re: [Obo-format] OBO to OWL (summary)

[<st...@in...>]

Sorting this out face to face seems like the best idea.


Quoting chris mungall <cj...@fr...>:

>
> sorry I haven't had time to properly partake. some sketchy responses  
> below. Nigam, Dilvan and I will meet f2f this week to discuss this 
> more
>
> On Sep 25, 2006, at 12:12 AM, Dilvan Moreira wrote:
>
>>   Hi,
>>
>>   The goal of this email is to summarize and unify our common
>> understanding of the OBO to OWL mapping. Please corrections and
>> suggestions are very much welcomed. I will try to focus on the open
>> questions, please refer to the Google spreadsheet "Common mapping" for
>> mapping details:
>> http://spreadsheets.google.com/ccc?key=pWN_4sBrd9l1Umn1LN8WuQQ
>>
>>   The main topics we didn't agree yet are:
>>
>> 1- The entities naming:
>> There is a consensus in using <some url>#<name>,
>
> Did we reach consensus on this?
>
> First of all, this is up to the obo ontology maintainer, they can  
> define their own URI prefix using the idspace tag - see the email I  
> sent on this
>
> The question is, what is the *default* policy for converting OBO IDs  
> to URIs, in cases where no idspace is specified
>
>> but we haven't
>> decided on the name yet. One suggestion is to use "-" instead of "_".
>
>
>
>> GO:0000001 would be http://<some URL>#GO-0000001 .
>
> What was the justification for "-" instead of "_"?
>
> If we go with the # over / as default, and we do prepend the obo  
> idspace to the local ID part, we should keep the form that has been  
> in use for production in GO over the last couple of years, eg 
> GO_0000001

seems reasonable

>> It allows the round
>> trip OBO->OWL->OBO for the same ids as the character "/". We would
>> like to avoid the use of "/" and "#" in the same file.
>
> I think the justification for this is poor. This requirement cannot  
> be satisfied if we use dc, as dc uses a / policy
>
>> We agree in having oboInOwl: and obo: as the prefixes for the
>> metamodel and contents, and ask for a more restricted definition of id
>> names in the OBO format (mandatory use of colon, etc).

/ has some advantages, and Jena 2.3 treats these namespaces better

>
> wait, you've lost me now. We would by default keep the contents of  
> *all* obo ontologies in one namespace?
>
>> 2- How to name the oboInOwl:DbXref individuals:
>
> The term "name" is confusing since it means something different in  
> the obof world from the owl world. You mean URI here
>
>> 2.1 Use Dbxref+hash values (it solves the problem of having  definitions)
>
> We will not do this!

any hash name would be the name of a bnode (RDFNode, not OWL individual)
in the OWL model, it would never appear in a file. Looking up the name 
of a node in the model
via a hash function is useful to avoid repeating dbname:acc data.

>
>> 2.2 Derive a name using dbname and acc (what to do when there are
>> characters that are forbidden in URIs)
>
> escape them

i don't think escapes are valid for & : and some other chars in genuine 
URIRefs
(it's fine for xsd:anyURI tags)

>> 2.3 Keep dbname and acc or make them into a label and use hasURI
>> whenever that is possible.
>>
>> 3. hasDefinition: Create a class to represent definitions (in the
>> hasDefinition annotation) with a label and DbXrefs or use a string for
>> the definitions and the hasDefinitionRef annotations to save the
>> DbXrefs.
>
> my vote is for the former. I realise that this will look less  
> intuitive in the default Protege/SWOOP display but I think this can  
> be remedied (eg with Stuart's plugin)
>
>> I believe the question here is if there is any value in
>> considering term definitions as individuals in the ontologies.
>
> yes. in future versions of obof there may be other things attached to 
>  the the text definition

there should be a uniform treatment of definitions, dbxrefs and synonyms
in terms of how bnodes are structured

>>
>> 4. Subsetdef: Are subsets part of the ontology as biological entities?
>> If so, shouldn't the terms have a hasSubset ObjectProperty
>> (restriction) with them as targets in place of a hasSubset
>> AnnotationProperty?
>
> subsetdefs are definitely not biological entities! subsetdefs are  
> simply views over the ontology, so membership is appropriately  
> modeled with AnnotationProperties
>
>> 5- Should the Synonym types (exact, broad, etc) be defined as
>> properties of the Synonyms or in the type of relation (hasBroadSynonym
>> etc) they have with the terms?
>
> I think we have to do it the former (ie as in Stuart's mapping)
>
> does the latter imply some level of reasoning over the synonym  
> relation types - in which case they can't be annotationprops, in  
> which case we'd be pushed to owl full?
>
>>
>> 6- What to do with isObsolete: Treat it as an annotation
>
> No!
>
>> or make the
>> obsolete terms decendants of the oboInOwl:Obsolete class?
>
> obsolete classes should not even be owl classes
>
>> 7- Why have a superclass for all classes of the metamodel?
>
> I can think of no reason
>
>>   Again, fell free to correct any mistakes or make any suggestions.
>>
>>   Cheers,
>>
>> -- 
>> Dilvan de Abreu Moreira, Ph.D.     di...@st...
>> SMI-Stanford Phone: 650-725 6236     http://java.icmc.usp.br
>> Warning: I use a spam filter, some emails sent to me CAN be lost!
>>
>
>