OBO2OWL Mappings
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRST
1
OWL individuals parent classOWL individual descriptionOWL Individual namingComments (for the rationale of the mapping)Comments SAComments Erick
2
oboInOwl:IdSpaceNot read by OBO parser

<oboInOwl:IdSpace bnode>
<rdfs:label...>"OBO prefix"</rdf:label>
<oboInOwl:hasURI rdf:datatype="... #anyuri">http:...</oboInOwl:hasURI>
<rdfs:comment> description </rdfs:comment> optional
</oboInOwl:IdSpace>
bnodeEach idSpace represents a mapping for an OBO prefix, such as GO:, to an URI, such as http://www.bioontology.org/2006/02/obo/go# .

Note that tools, such as OBO-Edit, do not implement idspace tags yet.
3
oboInOwl:DbXref to describe dbxref values.<oboInOwl:DbXref bnode>
<rdfs:label ...>SO:ke</rdfs:label>
< rdfs:comment> description </rdfs:comment>
<oboInOwl:hasURI rdf:datatype="... #anyuri">http:...</oboInOwl:hasURI>
optional, but if present has to be an URI
</oboInOwl:DbXref>
bnodeeach DbXref is treated as an individual because we might want to associate additional information with particular DbXrefs at a later datefine
4
oboInOwl:Synonym to describe synonym values<oboInOwl:Synonym bnode>
<rdfs:label...>"synonym-text"</rdf:label>
<oboInOwl:hasDbXref> DbXref ind </oboInOwl:hasDbXref> (optional)
<oboInOwl:hasSynonymType> SynonymType ind </oboInOwl:hasSynonymType> (optional)
</oboInOwl:Synonym>
bnodeeach Synonym is treated as an individual because we need to associate the source of the definition (as a DbXref). These are treated as bnodes (anonymous nodes) because the synonym individuals are terminological elements and not part of the ontology per se (hence no permenant ids for them). They are always associated with the corresponding ontological entity (the term ids in this case)fine
5
oboInOwl:ObsoleteClass for obsoleted termsThere are no individuals. Obsolete classes are children of this class. Same rdf:ID they would have if the term was not obsolete.Obsolete terms are not real entities anymore but we still need to know that they existed. Therefore we make them children the class called oboInOwl:ObsoleteClass and strip them of all their relationships.
6
oboInOwl:ObsoleteProperty for obsoleted properties<oboInOwl:ObsoleteProperty propertyID>
...
</oboInOwl:ObsoleteProperty>
Individuals are obsolete properties. Same rdf:ID it would have if the typedef was not obsolete.Obsolete relationships are not real entities anymore but we still need to know that they existed. Therefore we make them instances of the class oboInOwl:ObsoleteProperty (which is itself a child of the rdf:Property class) and strip them of al their relationships.
7
oboInOwl:SynonymType<oboInOwl:SynonymType CategoryID>
<rdfs:label ...>"categoryName"</rdf:label>)
<oboInOwl:restrictedToScope>"scope"</oboInOwl:restrictedToScope> (optional)
</oboInOwl:Subset>
Category ID. In
synonymtypedef: IUPAC_NAME "IUPAC NAME"
the category ID is IUPAC_NAME.
SynonymTypes (such as british spelling of a term) are not ontological entities. However these terminological elements are important to represent in the ontology file and so we create individuals (such as 'british_spelling') and then create an annotationProperty link b/w a Synonym and the SynonymTypeuse rdfs:label
8
oboInOwl:Subset<oboInOwl:Subset subsetName>
<rdfs:comment ...>"description-text"</rdf:comment> (optional)
</oboInOwl:Subset>
Name of the subsetEach Synonym subset provides a view on the ontology, we need this information in the same file to identify entities/terms that are members in this view. So we create individuals representing each subset (or view) and then create an annotationProperty link b/w a term and the subset of which it is a member. Subsets are not part of the ontology structure but need to be created from the ontology file. [subset descriptions have the potential to be very detailed and are thus more appropriate for a comment]use rdfs:label
9
oboInOwl:Definition<oboInOwl:Definition bnode>
<rdfs:label...>"definition-text"</rdf:label>
<oboInOwl:hasDbXref> DbXref ind </oboInOwl:hasDbXref> (optional)
</oboInOwl:Definition>
bnodeEach Definition is treated as an individual because we need to associate the source of the definition (as a DbXref). These are treated as bnodes (anonymous nodes) because the definition individuals are terminological elements and not part of the ontology per se (hence no permenant ids for them). They are always associated with the corresponding ontological entity (the term ids in this case)
10
OBO keywordOWL tagOWL element typeComments
11
Headerowl:Ontology
12
format-versionNot read by OBO parserGenerated back to OBO depending if the translation is OBO 1.0 or OBO 1.2.
13
data-versionowl:AnnotationProperty hasVersionxsd:stringAn owl:versionInfo statement generally has as its object a string giving information about this version, for example RCS/CVS keywords. This statement does not contribute to the logical meaning of the ontology other than that given by the RDF(S) model theory. owl:versionInfo is an instance of owl:AnnotationProperty.

Although this property is typically used to make statements about ontologies, it may be applied to any OWL construct. For example, one could attach a owl:versionInfo statement to an OWL class. -- therefore it is not restricted for use for the "whole ontology". data-version applied to the "whole ontology" and so we dont use owl:versionInfo.
Why not using owl:versionInfo? R. OK, but "rdfs:comment" and "rdfs:label" are also annotation properties, their use is not restricted for use for the "whole ontology". rdfs:comment is used for "remark". I do not see the reason for creating a new element if OWL already provides it. Otherwise, we have to be consistent and create a new property for "remark". Am I missing something?
14
versionDeprecated (since OBO 1.2) - same as data_version
15
dateowl:AnnotationProperty hasDatexsd:string (Generated back to OBO as current date)Agree with the AnnotationProperty but disagree with the xsd type. I'd rather use xsd:dateTime
16
saved-byowl:AnnotationProperty savedByxsd:string (generated back to OBO as current username)
17
auto-generated-byNot read by OBO parserGenerated back to OBO as the name of the tool being used to make the conversion.
18
subsetdefowl:AnnotationProperty hasSubsetoboInOwl:Subsetthe subset description becomes an rdfs:comment
19
importProcessed by the parserFound no example of use. It doesn't seem a direct mapping to OWL import. In any case, the parse doesn't give us access to this header value (it just import the files).We're dealing with some partitions of our big ontology (four sub-ontologies). I'd be glad if we can map this element...
20
synonymtypedefowl:AnnotationProperty hasSynonymTypeoboInOwl:SynonymType
21
idspaceNot read by OBO parser (owl:AnnotationProperty hasIdSpace)(oboInOwl:IdSpace)Note that tools, such as OBO-Edit, do not implement idspace tags yet.
22
default-relationship-id-prefixexpanded by the OBO parser
23
id-mappingexpanded by the OBO parser
24
default-namespaceowl:AnnotationProperty hasDefaultNamespacexsd:stringIt is missing from the OBO 1.2 spec !!!
25
remarkrdfs:comment
26
27
OBO keywordOWL tagOWL element typeComments
28
[Term]owl:ClassClass description
29
idmaps to URIOBO IDs have no defined syntax, but they are recommended to be of the
form <IDSPACE> ":" <LOCALID>. Future versions of the obo format spec
may get stricter. Currently all IDs in extant Obo files conform to the
recommended form, with the exception of IDs for relations defined in
the same ontology, and IDs for subsetsdefs. These IDs are "flat", as
they contain no ":". Flat IDs are problematic, and their use will be
clarified in future versions of the spec.

OBO IDs must be converted to URIs for use in OWL. The rules for
converting OBO IDs to URIs in the current mapping are as follows:

IF the obo header declares an idspace mapping of the form:

idspace: GO http://www.go.org/owl#

(note the trailing hash)

THEN all OBO IDs with the prefix GO: will be mapped to the provided URI:

http://www.go.org/owl#GO_0000001

IF an OBO prefix has not an idspace declaration it will be mapped to the default URI of the ontology (even if more than one prefix is present in the same file):

<default-base-uri>SO_0000001
<default-base-uri>CL_0000001

UNLESS the OBO ID is 'flat' (ie contains no ':'), in which case

id: foo

will be mapped to:

<default-base-uri>UNDEFINED_foo

EXCEPTION the OBO_REL: prefix is always implicitly declared with the following idspace:
idspace: OBO_REL http://www.obofoundry.org/ro/ro.owl

In OWL, we are always going to include the oboRel (for OBO_REL) and oboInOwl URIs:
xmlns:oboRel="http://www.obofoundry.org/ro/ro.owl#"
xmlns:oboInOwl="http://www.geneontology.org/formats/oboInOwl#"
(note that the actual URI may change in the future)

We have still to decide the default-base-uri, but we have decided it will end in a hash; e.g.

http://www.bioontology.org/oboContent/GO#

(flat IDs are problematic. Currently they only occur in some relation
declarations. We will work towards deprecating these, and forcing
people to qualify all IDs with an ID-space)

The proposed <default-base-uri> will move from the geneontology.org
namespace to the bioontology.org namespace, and will be something like
"http://www.bioontology.org/oboContent/<idspace>".

This will give default URIs of the form
"http://www.bioontology.org/oboContent/GO#GO_0000001". However, GO will
explicitly declare an idspace and other OBO ontologies will be
invited to do likewise.
ok, seems possible to implement in Protege
30
namerdfs:label
31
is_anonymousNO MAPPING
32
namespaceowl:AnnotationProperty hasOBONamespacexsd:stringIt is missing from the OBO 1.2 spec !!! ??
33
alt_idowl:AnnotationProperty hasAlternativeIdxsd:string
34
defowl:AnnotationProperty hasDefinitionoboInOwl:Definitionok
35
commentrdfs:commentok
36
subsetowl:AnnotationProperty inSubsetoboInOwl:SubsetThe object of this AnnotationProperty is an individual of type Subset defined in the header
37
synonymowl:AnnotationProperty hasSynonym
owl:AnnotationProperty hasExactSynonym scope=EXACT
owl:AnnotationProperty hasNarrowSynonym scope=NARROW
owl:AnnotationProperty hasBroadSynonym scope=BROAD
owl:AnnotationProperty hasRelatedSynonym scope=RELATED
oboInOwl:SynonymEach Synonym instance should be a bNodefine
38
exact_synonymDeprecated (since OBO 1.2) - same as synonym "text" EXACT
39
narrow_synonymDeprecated (since OBO 1.2) - same as synonym "text" NARROW
40
broad_synonymDeprecated (since OBO 1.2) - same as synonym "text" BROAD
41
related_synonymIt is missing from the OBO 1.2 spec !!! ?? It isn't declared deprecated.
42
xrefowl:AnnotationProperty hasDbXrefoboInOwl:DbXref individualok
43
xref_analogDeprecated (since OBO 1.2) - same as xref
44
xref_unknownDeprecated (since OBO 1.2) - same as xref
45
is_ardfs:subClassOfrdf:resource = parent owl:Class rdf:ID
46
intersection_of<owl:intersectionOf rdf:parseType="Collection">
<owl:Class ... />
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty ... />
</owl:onProperty>
<owl:someValuesFrom .../>
</owl:Restriction>
</owl:intersectionOf>
All intersection_of tags are read in to form the collectionglad we are mapping these into OWL
47
union _ofOWL equivalentAll union_of tags are read in to form the collection
48
disjoint_fromOWL equivalent
49
relationship<rdfs:subClassOf> <owl:Restriction> <owl:onProperty ... /> <owl:someValuesFrom .../> </owl:Restriction> </rdfs:subClassOf>owl:Property rdf:resource = owl:ObjectProperty rdf:ID & owl:someValuesFrom rdf:resource = owl:Class rdf:ID
50
is_obsoleteAn obsolete term isn't a real term - if a term stanza in the obo file is marked obsolete, then we make it a descendent of the oboInOwl:ObsoleteClass, with the same rdf:IDfine, no round-tripping for obsolete terms then?
51
use_termDeprecated (since OBO 1.2) - same as consider
52
replaced_byowl:AnnotationProperty oboInOwl:replacedByxsd:String = replacement Class OBO idChanged, now there can be more than one: There is 0 or 1 oboInOwl:replacedBy tags.
53
considerowl:AnnotationProperty oboInOwl:considerxsd:String = replacement Class OBO id
54
builtinDo not create OWL entity.Do not create an owl:Class for this obo term
55
56
OBO keywordOWL tagOWL element typeComments
57
[Typedef]owl:ObjectProperty
58
All annotation properties of Term except union_of, intersection_of disjoint_from.
59
owl:AnnotationProperty rdf:ID attribute generated from id.Typedefs are in the same OWL namespace as Terms, unless they are OBO_REL: relations, in this case they should point to the Relation ontology URI.
60
is_ardfs:subPropertyOfrdf:resource = parent owl:ObjectProperty rdf:ID
61
is_obsoleteAn obsolete typedef isn't a real typedef - if a typedef stanza in the obo file is marked obsolete, then we make it an instance of oboInOwl:ObsoleteProperty, with the same rdf:ID
62
domainrdfs:domainrdf:resource = parent owl:Class rdf:ID
63
rangerdfs:rangerdf:resource = parent owl:Class rdf:ID
64
inverse_ofOWL equivalent
65
transitive_overNO MAPPINGForthcoming in OWL 1.1
66
is_cyclicowl:AnnotationProperty isCyclicxsd:booleanRelatons in OWL can be cyclic, we keep this information for the round trip only.
67
is_reflexiveNO MAPPING
68
is_symmetricrdf:type owl:SymmetricPropertyChanges owl:ObjectProperty to owl:SymmetricProperty.
69
is_anti_symmetricNO MAPPING
70
is_transitiverdf:type owl:TransitivePropertyChanges owl:ObjectProperty to owl:TransitiveProperty.
71
is_metadata_tagNO MAPPING
72
73
OBO keywordOWL tagOWL element typeComments
74
[Instance]NO MAPPINGWe will not implement them yet.
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
Main menu