-
Notifications
You must be signed in to change notification settings - Fork 29
/
references-edit.omn
2712 lines (1896 loc) · 98.3 KB
/
references-edit.omn
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Prefix: dc: <http://purl.org/dc/elements/1.1/>
Prefix: obo: <http://purl.obolibrary.org/obo/>
Prefix: ubref: <http://purl.obolibrary.org/obo/uberon/refont/>
Prefix: owl: <http://www.w3.org/2002/07/owl#>
Prefix: rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Prefix: url: <http://www.w3.org/2000/01/rdf-schema#seeAlso>
Prefix: xml: <http://www.w3.org/XML/1998/namespace>
Prefix: xsd: <http://www.w3.org/2001/XMLSchema#>
Prefix: body: <http://purl.org/dc/elements/1.1/description>
Prefix: rdfs: <http://www.w3.org/2000/01/rdf-schema#>
Prefix: year: <http://purl.org/dc/elements/1.1/date>
Prefix: title: <http://purl.org/dc/elements/1.1/title>
Prefix: source: <http://purl.org/dc/elements/1.1/source>
Prefix: creator: <http://purl.org/dc/elements/1.1/creator>
Prefix: minipub: <http://purl.org/dc/elements/1.1/resource>
Prefix: abstract: <http://purl.org/dc/elements/1.1/abstract>
Prefix: pso: <http://purl.org/spar/pso/>
Prefix: ice: <http://purl.obolibrary.org/obo/IAO_0000030>
Ontology: <http://purl.obolibrary.org/obo/uberon/references/references.owl>
Annotations:
dc:title "Uberon ontology documentation"^^xsd:string,
dc:creator "Chris Mungall"^^xsd:string
AnnotationProperty: ubref:superseded_by
AnnotationProperty: ubref:has_status
Class: <http://purl.org/spar/pso/Status>
Annotations:
rdfs:comment "A state or condition that a document may have."@en,
rdfs:label "status"@en
Individual: <http://purl.org/spar/pso/initial-draft>
Annotations:
rdfs:label "initial draft"@en,
rdfs:comment "The status of pre-publication material (for example a document or a dataset) when in its initial stage of development."@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/final-draft>
Annotations:
rdfs:label "final draft"@en,
rdfs:comment "The status of pre-publication material (for example a document or a dataset) when in the authors' opinion it has been brought to a stage of development that renders it suitable for publication."@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/peer-reviewed>
Annotations:
rdfs:seeAlso <http://purl.org/spar/pso/reviewed>,
rdfs:label "peer reviewed"@en,
rdfs:comment "The status of a publication, typically a scholarly journal article, that has been peer reviewed, i.e. subjected to review by two or more independent reviewers (also know as referees) who are academic peers of the author(s), and judged by them to be of sufficient quality to merit publication, usually after further revision by the author to incorporate the reviewers' suggested modifications and improvements."@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/intermediate-draft>
Annotations:
rdfs:comment "The status of pre-publication material (for example a document or a dataset) part-way through its development."@en,
rdfs:label "intermediate draft"@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/withdrawn-from-submission>
Annotations:
rdfs:comment "The status of material (for example a pre-publication document or dataset) that has been voluntarily withdrawn by the author from a previous status of having been submitted for publication, perhaps because the revision demands requested by the peer-reviewers were considered impossible to achieve, or because the author wishes to submit it for publication elsewhere."@en,
rdfs:label "withdrawn from submission"@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/reviewed>
Annotations:
rdfs:label "reviewed"@en,
rdfs:seeAlso <http://purl.org/spar/pso/peer-reviewed>,
rdfs:comment "The status of a publication, for example a book, that has been subjected to a written review and critical analysis of its content, scope and quality."@en
Types:
<http://purl.org/spar/pso/Status>
Individual: <http://purl.org/spar/pso/under-review>
Annotations:
rdfs:comment "The status of a document that has been received from the author(s) by an editor or a publisher for potential publication, and then has been sent to independent reviewers for their comments as to its suitability for publication, prior to receipt of such reviews."@en,
rdfs:label "under review"@en
Types:
<http://purl.org/spar/pso/Status>
AnnotationProperty: dc:creator
AnnotationProperty: dc:contributor
AnnotationProperty: rdfs:seeAlso
AnnotationProperty: dc:abstract
AnnotationProperty: dc:source
AnnotationProperty: dc:subject
AnnotationProperty: dc:date
AnnotationProperty: rdfs:label
AnnotationProperty: dc:description
AnnotationProperty: dc:title
Datatype: xsd:anyURI
Datatype: xsd:int
Datatype: xsd:string
Class: ice:
Annotations: rdfs:label "information content entity"@en
Class: ubref:ontology_documentation
Annotations: rdfs:label "ontology documentation"@en,
dc:description "Documentation describing an ontology or some aspect of an ontology"
SubClassOf: ice:
Class: ubref:ontology_design_pattern
Annotations:
rdfs:label "ontology design pattern"@en,
dc:description "A template or design pattern that is repeated multiple kinds",
rdfs:seeAlso "http://www.springerlink.com/content/d2lp476v0p281q73/"^^xsd:anyURI
SubClassOf: ubref:ontology_documentation
Class: ubref:description_of_a_meeting
Annotations: rdfs:label "description of a meeting"@en,
dc:description "Some combination of: a meeting report, meeting minutes or a description of the outcomes of a meeting"
SubClassOf: ubref:ontology_documentation
Class: ubref:spreadsheet_documentation
Annotations: rdfs:label "spreadsheet documentation"@en,
dc:description "A description of and link to a spreadsheet that contains domain knowledge in tabular form"
SubClassOf: ubref:ontology_documentation
Class: ubref:metadata_description
Annotations: rdfs:label "metadata description"@en,
dc:description "Documentation describing the metadata or metadata best practices used in an ontology"
SubClassOf: ubref:ontology_documentation
Class: ubref:biological_modeling
Annotations: rdfs:label "biological modeling"@en,
dc:description "Documentation describing how a specific piece of biology is represented in the ontology"
SubClassOf: ubref:ontology_documentation
Class: ubref:ontology_usage_article
Annotations: rdfs:label "ontology usage article"@en,
dc:description "Documentation describing how a particular piece of the ontology is intended to be used"
SubClassOf: ubref:ontology_documentation
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000000>
Annotations:
ubref:has_status <http://purl.org/spar/pso/intermediate-draft>,
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:title "UDoc - the Uberon documentation system"^^xsd:string,
rdfs:label "UDoc - the Uberon documentation system"^^xsd:string,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/About-documentation>,
dc:description "
## Summary
This article describes the inline documentation system used by
Uberon. The article is itself a component of the system.
## Background
Documentation is essential for ontology development. yet there is no
standard way to document an ontology. In addition, there is a tendency
for external documentation (wiki pages, web pages, etc) to drift from
the ontology.
## Embedded documentation
This ontology aims to be as self-documenting as possible. In addition
to the standard metadata associated with each class, we embed articles
in the ontology. These articles may describe abstract design patterns
or templates that are repeated throughout the ontology, or the
modeling of a particular piece of biology (e.g. the heart). Some
articles are of interest to users of the ontology, as they describe in
more detail the system being represented and why it was represented in
a particular way. Other articles may be solely for the developers of
the ontology.
## Model
Each article is represented as an individual, and gets a unique
URI. For example, the URI for this article is
[http://purl.obolibrary.org/obo/uberon/references/reference_0000000](http://purl.obolibrary.org/obo/uberon/references/reference_0000000).
Each article is then adorned with metadata, using properties from
vocabularies such as dublin core. The text of the article is
represented using dc:description with a string value. The text is
authored using a variant of markdown syntax, which can then be
translated to html.
Each article is of a specific type. The categories used include:
* ontology documentation
* biological modeling
* ontology design pattern
* metadata documentation
Currently the documentation system assumes a flat hierarchy and
assertions to leaf nodes. The vocabulary used for the above is not yet
stable.
Any properties can be used, but the recommended set is:
* dc:date (1) (currently the year as an int, for historic reasons)
* dc:creator (1 or more) - the main author(s)
* dc:contributor (0 or more)
* dc:title (1, required)
* dc:abstract (1, required)
* dc:description (1, required) in markdown format
* rdfs:seeAlso (0 or more) - links to other related articles or resources
The publishing status ontology (pso) is used to give each article a
status such as 'initial-draft'
## Connecting articles to ontology elements
Each article can be references multiple times in the main ontology, in
different ways.
Sometimes a class may point to an article - for example, if an
ontology class implements a certain design pattern or template
described in an article, then a 'implements design pattern' annotation
property connects the two.
Sometimes it may be more appropriate to link an axiom annotation to an
article.
## Referencing external sources
It is not always appropriate to cram everything into a single article
that is embedded in the ontology. The seeAlso property can be used to
connect out to googledocs, spreadsheets, ontogenesis articles,
textbooks, etc.
## Viewing articles
Articles can be viewed when references.owl is loaded alongside the
main ontology in the ontology editing environment, but this is not
appropriate for everyone.
Each article can be viewed on the web via its purl
## Guidelines for authors
Ontology editors should edit the file references-edit.omn [in
git](https://github.com/cmungall/uberon/tree/master/reference) - any
new articles created should be in their idrange - see
uberonref-idranges.owl.
The file can be edited in a text editor (the recommended text editor
emacs plus Phil Lord's omn-mode.el, plus ubref-helper.el). Note that
the author should be adept in manchester notation.
The prefered route is to open the articles ontology in Protege,
navigating to the 'individuals by type' tab (insert image here).
In both cases, the main text should go in the dc:description tab using
markdown format. Note that hashes should be used for headings rather
than underlines.
The format used is a variant called ontology markdown. Class labels
can be written in backtics - the derived documentation will make PURL
links from these (*to be implemented*).
In general each article type should follow a certain template (to be
documented).
The ontology release manager will generate the derived documentation
from this file.
## Implementation
The current implementation is somewhat ad-hoc and may be replaced.
The references-edit.omn is translated to an rdf/owl ontology -
[references.owl](http://purl.obolibrary.org/obo/uberon/references.owl)
A perl script (owldoc2md.pl) generates individual markdown (.md) files
from this owl file (using a to-be-released API). It assumes some of
the annotation properties listed above are used.
Each markdown file is then converted to an html file using pandoc.
The html file has the same name as the localname of the URI. It is
committed to svn, and the svn property svn:mime-type is set to
text/html
## Acknowledgments
This system was inspired by Matt Brush's REO documentation system
developed at OHSU, and by David Osumi-Sutherland's org-mode system, as
well as by Phil Lord's articles on ontology documentation and applying
literate programming ideas to ontologies.
"^^xsd:string
Types:
ubref:metadata_description
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000030>
Annotations:
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:contributor "Heiko Dietze"^^xsd:string,
dc:title "Continuous integration"^^xsd:string,
rdfs:label "Continuous integration"^^xsd:string,
rdfs:seeAlso "http://bio-ontologies.knowledgeblog.org/405"^^xsd:anyURI,
rdfs:seeAlso "http://build.berkeleybop.org/job/build-uberon/"^^xsd:anyURI,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/Continuous-integration>,
dc:abstract "
In software engineering, continuous integration (CI) implements
continuous processes of applying quality control - small pieces of
effort, applied frequently. The same techniques can be applied to
ontology engineering - this is especially important for integrative
ontologies, where changes in one ontology can have effects on other
ontologies.
"^^xsd:string,
dc:description "
## Background
Classes in Uberon subsume classes in species-specific anatomy
ontologies. In addition, Uberon is interconnected with other
ontologies such as CL, GO and phenotype ontologies. These ontologies
are developed in an asynchronous manner by different distributed
groups. With this type of development, there is the possibility of
inconsistencies arising between ontologies.
Integration tests verify that two or more ontologies are compatible -
i.e. combining them in an import chain together with bridging axioms
does not produce any unsatisfiable classes. For example, if MA were to
accidentally place 'styloopod' as a part of a forelimb, a reasoner
would find an unsatisfiable class in the integrated ontology set,
because in uberon fore and hindlimbs are spatially disjoint.
Integration tests can be time consuming to debug and resolve. The
software engineering principle of Continuous Integration (CI) holds
that integration tests should be done as far upstream as possible in
the development cycle. This means problems can be detected and
resolved immediately, rather than building up over time.
## The OBO-Jenkins CI system
The [OBO CI system](http://build.berkeleybop.org/) uses the Jenkins CI
server to perform integration tests over multiple OBO ontologies.
The system consists of a set of jobs, each performing a particular set
of tests. These jobs are typically triggered by a commit to a Version
Control System (VCS) such as SVN.
For example, whenever an Uberon editor commits to the core github
repository, the
[build-uberon](http://build.berkeleybop.org/job/build-uberon/) job is
queued. This job executes a number of scripts and runs Oort to perform
a build. If a problem is found, Jenkins will email the committer.
In addition, cross-anatomy builds are triggered whenever an external
AO commits (currently just ZFA, MA and EHDAA2). This checks that the
union of Uberon and this AO plus bridging axioms is satisfiable.
### Jobs
The following Jobs involve Uberon:
* [build-uberon](http://build.berkeleybop.org/job/build-uberon/)
* [build-go-xp-uberon](http://build.berkeleybop.org/job/build-go-xp-uberon/)
* [check-uberon-ehdaa2](http://build.berkeleybop.org/job/check-uberon-ehdaa2/)
* [check-uberon-ma](http://build.berkeleybop.org/job/check-uberon-ma/)
* [check-uberon-zfa](http://build.berkeleybop.org/job/check-uberon-zfa/)
* [build-phenoscape](http://build.berkeleybop.org/job/build-phenoscape/)
## Future developments
Currently Jenkins is only used as a verification step for Uberon - the
build process requires multiple steps governed by a complex Makefile,
the components of which are currently being migrated to Jenkins.
In the future we intend to add additional cross-species Jobs.
"^^xsd:string
Types:
ubref:metadata_description
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000032>
Annotations:
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:title "Automatic inference of part_of relationships"^^xsd:string,
rdfs:label "Automatic inference of part_of relationships"^^xsd:string,
dc:abstract "..."^^xsd:string,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/Inferring-part-of-relationships>,
dc:description "
Level of difficulty: advanced
## Problem
Given
* `metaphysis of femur` EquivalentTo `metaphysis` and part_of some `femur`
* `diaphysis of femur` EquivalentTo `diaphysis` and part_of some `femur`
* `metaphysis` SubClassOf part_of some `diaphysis`
It might seem that we should be able to infer:
* `metaphysis of femur` SubClassOf part_of some `diaphysis of femur`
But this is not the case, for good reason. The reasoner will infer
that a femur metaphysis is both part of a diaphysis and part of a
femur, but it cannot rule out that this diaphysis and this femur are
only partially overlapping.
## OWL Solution
We can get the axioms we want by adding additional general axioms:
* (part_of some `diaphysis` and part_of some `femur`) SubClassOf part_of some `diaphysis of femur`
This is not highly intuitive for ontology developers
## Heuristic Solution (current)
We instead opt for a *heuristic* solution. We have a rule that has the antecedents:
* X EquivalentTo PX and part_of some W
* Y EquivalentTo PY and part_of some W
* PX SubClassOf part_of some PY
And consequents:
* X SubClassOf part_of some Y
Note that this rule is *not safe*. However, they can form the basis of
suggestions which can be implemented by the ontology editor.
## Alternate Solutions (future)
We might want to automatically generate axioms of this form:
* (part_of some `diaphysis` and part_of some `femur`) SubClassOf part_of some `diaphysis of femur`
Using rules; for example:
IF
* P SubClassOf `zone of long bone`
* W SubClassOf `long bone`
THEN generate:
* (part_of some P and part_of some W) SubClassOf part_of some (P and part_of some W)
"^^xsd:string
Types:
ubref:ontology_design_pattern
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000034>
Annotations:
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:title "Digestive tract"^^xsd:string,
rdfs:label "Digestive tract"^^xsd:string,
dc:abstract "..."^^xsd:string,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/The-digestive-tract>,
dc:description "
## Digestive Tract
We follow Kardong in defining the digestive tract as a tube extending
from mouth to anus. We use this definition across bilateria.
Note that various other terms are used for other divisions or parts of
the digestive system, for example
* alimentary tract - in Kardong, the portion of the DT after the pharynx
* digestive system - DT plus various organs
* gut - ambiguous term, sometimes synonymous with DT, sometimes intestines
Reference: Kardong, fig 13.1
## Subdivisions of the digestive tract
Like any tube, the DT can be subdivided along its main axis, which we
call the proximal-distal axis (terminology may vary across species;
e.g. in some metazoans the terms oral-aboral may be used)
Multiple overlapping subdivisions may exist.
A standard list of divisions order proximal-distal for vertebrates is
* `mouth`
* `pharynx`
* `esophagus`
* `stomach`
* `intestine`
Note that some subdivisions may simultaneously be considered organs
and tube subdivisions.
Note that the the same 4 terms may also be used in non-chordates for
analagous structures. We tend to reserve these labels for vertebrates,
and use functional grouping classes such as `food storage organ`.
There are variations and subdivisions of this scheme in vertebrates;
e.g. the esophageal structures of avians; the stomachs of ruminants;
divisions of the intestine in mammals. See Kardong for details.
A 'combined' vertebrate pattern may be
* `mouth`
* `pharynx`
* `nasopharynx`
* `oropharynx`
* `hypopharynx`
* `esophagus` (may have: crop)
* `stomach` (may have: proventriculus, gizzard, multiple 'sub-stomachs'; absent in species such as zebrafish)
* `intestine`
* `small intestine`
* `duodenum`
* `jejunum`
* `ileum`
* `large intestine`
* `colon`
* `rectum`
Note we treat the caecum as a diverticulum and not a true section of the DT
## Anatomy of a digestive tract subdivision
The DT can be subdivided along a proximal-distal axis. Each
subdivision will typically have similar parts. Minimally: a wall, and
a lumen, bounded by the wall.
We use the class `subdivision of digestive tract` for any section of
the tube, including the wall and lumen.
In vertebrates the a subdivision typically contains:
* `mucosa`
* `epithelium`
* `lamina propria` (lamina propria mucosae)
* `muscularis mucosa` (lamina muscularis mucosae, lamina muscularis) - smooth
* `submucosa`
* `muscularis propria` (muscular coat, muscle/ular layer, muscularis externa) - typically smooth
* `circular muscle`
* `longitudinal muscle`
* `serosa` or `adventita`
Glands may occur in the mucosa, submucosa or outside the walls
Sometimes it is also useful to create a class 'smooth muscle of
X'. Note that this may encompass both muscularis mucosa and the
non-adjacent muscular coat - although in some sections, such as the
esophagus, this is skeletal muscle. At the time of writing, some parts
of the ontology may need to be verified for consistency - in some
cases, smooth muscle may be bundled together with the muscularis
propria
## Ends of the digestive tract
In metazoans, the DT is typically open at both ends - the mouth and
the anus.
We attempt to clearly distinguish between the opening itself (an
orifice or aperture), the terminal portion of the tube (which
encompasses the opening an extends along the tube some distance), and
the lumen of that terminal portion. Terminology is often quite loose
here.
For the proximal section we have:
* `oral opening` - orifice
* `mouth` - terminal subdivision
* `oral cavity` - lumen of mouth, aka buccal cavity
We propose that these classes can be used across metazoans. In
vertebrates the mouth typically contains tongue, teeth, etc, and
extends to the pharynx.
There is some inconsistency in various anatomy ontologies as to the
extent of the mouth. See section on AOs below
For the distal section we have:
* `anus` - orifice
* `terminal part of digestive tract`
* `lumen of terminal part of digestive tract`
We propose that these classes are also used across metazoans.
The term 'rectum' may sometimes be used as a synonym for the terminal
portion, but in vertebrates it used more specifically for the terminal
portion of the large intestine, which is not necessarily the terminal
portion of the DT when a cloacal chamber is present.
### Cloacal chambers
We use the term `cloaca` to refer exclusively to the chamber present
in many mostly non-mammalian vertebrates into which the digestive and
urogenital system empties.
The cloaca may be considered part of the DT, but it is also part of
the genitourinary system. In vertebrates with a cloaca, we consider
the rectum to be the terminal part of the intestine, emptying into the
cloacal chamber.
Note that in vertebrates the anus is considere to be the opening at
the end of the rectum. If the DT is considered to extend past the
rectum and include the cloaca and the cloacal opening, then the anus
is no longer the end of the DT. For simplicity we may consider the DT
proper to end with the rectum/anus in vertebrates, and the cloaca to
be a hindgut derivative that is not part of the DT proper, but still
part of the digestive system (and urogenital and excretory
system). TBD.
Mammals have an embryonic cloaca.
## Embryonic subdivisions
One subdivision of the gut is as follows
* `foregut`
* `midgut`
* `hindgut`
These are defined very generally for bilateria. For vertebrates,
standard borders are used. See ontology for details.
## Diverticula and derived structures
Some structures start as diverticula of the embryonic DT. We consider
these to be not part of the DT, but they may still be part of the
digestive system. Different subdivisions apply for systems.
## Inconsistencies amongst various anatomy ontologies
### Mouth and oral region
MA has distinct classes for mouth an oral region, with the following
parts:
* tonsil: O
* tongue: O
* oral epithlium: O
* soft palate: O
* salivary gland: O, M
* oral region cartilage bone: O, M
* tooth: O, M
* gingiva: O, M
* oral mucosa: M
* lip: M
* palate: M
We merge these in Uberon
In FMA, the mouth contains salivary glands, dentition, lips, mucosa,
soft palate.
EHDAA2 has no class 'mouth', but 'oral region' corresponds to mouth
The tongue and the palate are considered part of the face in FMA (as
well as part of the mouth)
"^^xsd:string
Types:
ubref:ontology_design_pattern
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000035>
Annotations:
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:title "Conflation and Discrimination"^^xsd:string,
rdfs:label "Conflation and Discrimination"^^xsd:string,
dc:abstract "..."^^xsd:string,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/Conflation-vs-discrimination-Design-Pattern>,
dc:description "
Ontology builders are often confronted with situations in which they
have to decide whether to model a piece of biology using a single
concept vs breaking that concept into ontologically distinct classes.
For example, in the brain, neural nuclei cluster into complexes. The
ontology designer is faced with a decision as to whether to represent
this using distinct classes for the nuclei and the complex, or whether
to bundle them into one. We call the former 'de-conflation' and the
latter 'conflation'.
The choice is often determined by what the ontology is to be used
for. To support basic indexing, search and gene expression queries,
conflation is a good strategy because it lessens the complexity of the
ontology with few negative results for querying.
However, excessive conflation can lead to problems when axiomtizing
the ontology for reasoning, or when integrating the ontology with
other ontologies.
The problem is especially apparent when an ad-hoc mixing of conflation
and de-conflation is used. This leads to situations where subclass and
part-of are interchanged arbitrarily.
## Principle
The general principle in Uberon is to be cautiously
de-conflationary. The idea is that it is easier to automatically
conflate distinct related concepts (for the purposes of queries, etc)
than it is to automatically de-conflate a conflated concept. At the
same time, care must be taken to avoid the ontology inflation that
comes with de-conflation
When de-conflation is used, we make sure relations are available that
connect the de-conflated classes.
The most important principle to be consistent in the strategy used,
and to be clear as to what a class represents.
## Relations
### The composed_primarily_of relation
## Patterns
### Cells vs simple tissues
Examples:
* epithelium vs epithelial cell
* skeletal muscle cell vs skeletal muscle tissue
Solution:
We always de-conflate here, with the cell type represented in CL. For
simple tissues, we use logical definitions of the form:
* 'X tissue' EquivalentTo tissue and composed_primarily_of some X
### Lumens and cavities vs cavitated structures
Examples:
* ventricles - spaces or structures?
### Skeletal subdivisions vs organism subdivisions
Examples:
* hand vs skeleton of hand
* head vs skull
* digit vs digit skeleton
(see reference_0000003 for more on this topic)
Solution:
We always de-conflate here, as these are distinct classes.
In addition, we always try and mirror subdivisions, even though this
leads to ontology inflation.
### Skeletal subdivisions vs bones
Examples:
* `bone of hand` vs `skeleton of hand`
*
### Muscles and musculature
### Vessels and vasculature
### Neural nuclei
## Tools
De-conflation in the ontology can make the ontology harder to use for
simple search and querying. For certain kinds of queries it is
irrelevant whether a phenotypes affect an X vessel or X vasculature.
"^^xsd:string
Types:
ubref:ontology_design_pattern
Individual: <http://purl.obolibrary.org/obo/uberon/references/reference_0000036>
Annotations:
dc:date "2012"^^xsd:int,
dc:creator "Chris Mungall"^^xsd:string,
dc:contributor "Frederic Bastian"^^xsd:string,
dc:contributor "Melissa Haendel"^^xsd:string,
dc:contributor "Fabian Neuhaus"^^xsd:string,
dc:contributor "David Osumi-Sutherland"^^xsd:string,
dc:title "Developmental stages"^^xsd:string,
rdfs:label "Developmental stages"^^xsd:string,
dc:abstract "..."^^xsd:string,
ubref:superseded_by <http://purl.obolibrary.org/obo/uberon/docs/Modeling-developmental-stages>,
dc:description "
This document describes how developmental and life cycle stages are
represented in Uberon. It is intended for users, ontology developers,
and contributing ontologies.
## Distinction between stages and anatomical structures
We have two disjoint hierarchies for stages and structures. This has
certain consequences that are not ideal for everyone. For example, we
have distinct classes for `larva` and `larva stage` - other
ontologies may conflate these.
There is also an increase in the number of relationship types used.
To avoid confusion we use strict terminological rules, with all stage
classes having a label such as 'X stage', corresponding to a
whole-organism structure called 'X'.
## Distinction between stages and GO biological processes
We treat these as distinct, although both are subtypes of bfo
'occurrents'. Again this can seem to lead to an increase in the number
of terms, as we have both 'gastrulation' (GO) and 'gastrula stage'
(Uberon). These are linked by the coincides_with relation.
## Relationship types
We use a variety of relationship types for connecting stages to
eachother, and for connecting stages to structures. These relations
are based on work by Fabian Neuhaus and David Osumi-Sutherland and
will be described in more detail in a subsequent publication. A brief
overview is provided here.
Stages are subdivided using the part_of relation. Each stage always
has at least one subclass axiom (isa parent). This is typically to the
parent `life cycle stage`.
Stages are ordered in succession via the preceded_by relation (MAY
CHANGE TO starts_at_end_of). Note the distinction between direct and
transitive precedence. An adult stage is always preceded by an
embryonic stage, but it need not be *directly* preceded by this stage.
## Core generic classes
### Broad subdivisions
The core distinction is between embryonic stages and post-embryonic
stages. In some animals there are other stages such as larval.
### Early embryonic stages
The early development stages in Uberon are taken from BILA and
describe a typical sequence of development found across metazoa, up
until gastrulation
### Embryo vs fetus
TODO - Documentation will be added here later
### Post-natal stages
Uberon uses sexual maturoty as the core developmental landmark. This
leads to a slight disjunction between terminology applied to humans
and other animals. We are working on the best way to resolve these.
### Late adult stages and sensescence
TODO - Documentation will be added here later
We may use the NIFSTD subdivisions developed by Bill Bug here, but
this may better be treated in a dedidcated human staging ontology
## Species-specific stages
As a general rules, Uberon leaves species-specific classes to
dedicated species ontologies. The ontologies together form a
federation, which can be consumed either via composite or importer
ontologies (see ADD LINK HERE).
Staging schemes are typically devised for a specific species (and
often a stereotypical member of that species), and thus fall outside
the purview of Uberon core. We provide some rules for species anatomy
developers to assist the federation process.
### Federation guidelines
In order of preferences, stage ontologies should:
* be logically consistent with core uberon generic stages
* use identifiers that are conformant to OBO guidelines
* isa-complete
* uses isa vs part_of in the correct way
* be openly released at a reasonable frequence, and be resposibe to reasonable requests
* uses intermediate subdivisions where appropriate (ie isn't a flat list)
* uses preceded_by relationships to create a temporal ordering - this should be a total order on the leaf nodes
* use standard naming conventions
* names stages such that they won't be confused with corresponding structures (e.g. 'embryo stage' vs embryo)
* includes numeric timing info using OWL datatypes (e.g. has_day 23^^xsd:int)
Currently it is difficult to federate mammalian staging ontologies, we
are working on solutions here.
### Alternate staging schemes for a single species
There may be more than one overlapping staging scheme for an
organism. Currently these are not represented in Uberon, or in any of
the federated ontologies. If there is demand for these, we would be
willing to work with federated ontologies in capturing this knowledge.
### Mapping inter-species-specific staging schemes
As mentioned previously, staging schemes are species specific. Even
within the mammals, once gastrulation is over we do not break down the
embryonic stage into more refined pan-mammalian stages.
It may be possible to align Carnegie stages and Thelier stages at a
higher level of granularity. We have no immediate plans to do this,
but users interested in an automated approach to this should consult
Aitken at el (TODO: PMID).
## Structure-specific staging
Staging schemes can be applied to anatomical structures as well as the
whole organism - for example, limb staging. It is not clear the
situations where this helps, given that we may already have the
structures themselves subtypes (e.g. limb bud vs limb) and the
devlopmental processes may be described in GO. The GO cell cycle
subset can also be considered to be redundant with a staging ontology
for cell types.
Currently (Jan 2013) we do not have non-life cycle stages in Uberon,
but this may change in the future.
The FBdv ontology contains some good examples of stages for anatomical
structures.
## Stage subset
The stages in uberon are available as a separate subset ontology
(TODO: add link)
## Provenance
The backbone of the Uberon staging system was lifted directly from
BILA. Future development was done in collaboration with the Bgee
group. We also made use of the XUO ontology developed by Stuart