Ontologies – Page 2 – OpenCitations blog

Current Projects at the Image Bioinformatics Research Group in Oxford

Alistair Miles, of SKOS fame, who formerly worked in our research group, spent yesterday afternoon catching up with us, and has written a nice blog post on the MalariaGEN Informatics Blog describing our current activities, including our work on the Open Citations Corpus, and how they might intersect with the data management activities of the MalariaGEN, the Malaria Genome Epidemiology Network for which he now works.

He has also written a separate blog post reflecting on the work he did when in our group working on the JISC FlyWeb Project to develop openflydata.org, as an update on his earlier post, which is well worth a read if you wish to understand how semantic web techniques can be used to integrate data from heterogeneous and non-compatible databases in distributed locations.

Graham Klyne, who was part of that FlyWeb Project, has been instrumental in taking those same ‘data web’ data integration techniques and re-applying them to data integration in the classical arts, using the CIDOC-CRM data model developed for the museum community, to underpin CLAROS, The World of Art on the Semantic Web. It now looks as though Graham’s current work with Jun Zhao and others on the provenance of bioinformatics workflows, within the EU Workflows4Ever Project, might be of assistance to Al in his current work with Plasmodium SNP discovery and genotyping pipelines for MalariaGEN.

It’s nice to stand back from time to time and see all these activities interlinking as a whole. Thanks, Al.

My next two posts follow on from this, in that the first explores reasons why the majority of researchers don’t presently publish the datasets underlying their research articles , and the second summarizes the various JISC projects in which we are involved as a research group, including the Open Citations Project, that seek to mitigate this problem and provide tools and services that make data publication and subsequent data citation easier.

Nomenclature for citations and references

Reis et al. (2008) [1] cites an earlier paper from Albert Ko’s research group, Ko et al. (1999) [2].

In conventional parlance, as the following diagram shows, the word “reference” can mean either what is found in the text, what is found in the reference list, the act of citation, or the object of the citation itself, as in the sentence “All the references you will need to prepare for the journal club are on Kevin’s desk”.

This situation does not make for unambiguous machine-readable encoding, so to improve the situation we have, in the SPAR (Semantic Publishing and Referencing) Ontologies, introduced a more principled way of referring to these items and actions, as the second diagram illustrates:

This permits us to create RDF describing all aspect of the citation process. Within the body of the text we have an in-text citation containing an in-text reference pointer, while the actual bibliographic reference that the in-text reference pointer denotes is to be found within the article’s reference list. That bibliographic reference references the cited article, while the whole performative act of including the reference in the article constitutes the act of citation.

Are we all clear now?

[1] Reis RB, Ribeiro GS, Felzemburgh RDM, Santana FS, Mohr S, Melendez AXTO, Queiroz A, Santos AC, Ravines RR, Tassinari WS, Carvalho MS, Reis MG, Ko AI (2008) Impact of Environment and Social Gradient on Leptospira Infection in Urban Slums. PLoS Negl Trop Dis 2(4): e228. doi:10.1371/journal.pntd.0000228

[2] Ko AI, Reis MG, Ribeiro Dourado CM, Johnson WD Jr, Riley LW and the Salvador Leptospirosis Study Group. (1999) Urban epidemic of severe leptospirosis in Brazil. Lancet 354: 820–825. doi:10.1016/S0140-6736%2899%2980012-9.

How to cite data

As an approach towards developing best practice for data citation, I recently wrote a Data Citation Best Practice Discussion Document that is available on Google Docs, and that I have now slightly revised to Version 2 [1].

In that document, I first compared what is recommended by DataCite [2] and by Altman and King [3] with what currently practised by the Dryad Data Repository and what presently occurs ‘in the wild’ in a handful of journal articles that reference Dryad datasets. I then proposed some ‘internal’ recommendations for Dryad to adopt, and concluded with draft Data Citation Best Practice Recommendations. As I say in the preface to the document:

“Since Dryad is pioneering data management in terms of data resources that are linked to journal articles, it is to be hoped that by first developing citation best practice in the Dryad context we can thereby catalyse its wider spread. If we can thus agree what such best practice should be among the Dryad community and implement such best practice proposals, we can then promote such practices within the wider scholarly community.”

I realized that much of the confusion and disagreement concerning the best method of citing data resources within earlier e-mail threads resulted from a conflation of ideas about two entities which in the conventional citation of journal articles are quite distinct:

the in-text citation containing an in-text reference pointer, e.g. “this paper builds upon the work of Jones et al. [15].” and

the actual reference to Jones et al. within the article’s reference list, e.g. “[15] Jones A, Bloggs B and Smith C (2008). Title. JournalName
14:132-134. doi:*****.”

Thus, in an e-mail I wrote on 27 April, where I said

“Excellent, but what we really want is for the data citations to be included in the reference list along with the bibliographic citations, following the DataCite model: Creator (PublicationYear): Title. Version. Publisher. ResourceType. Identifier “

. . . I should also have stressed the need for explicit in-text citations that denote such references.

All that is explained within the Google Docs paper. In that paper I also proposed having a separate Data Resources section within the body text of a journal article, in which data resource citations can be gathered. That does not preclude these resources also being cited, where appropriate, within the Methods and Materials or Results sections of the paper, but is designed to put data resource citations “on the map”, so to speak, as important new publication performative acts.

It is not appropriate, in my mind, for data citations to be included in the Acknowledgements section of a paper, which is designed for acknowledging contributions to the work from people and funding agencies, even if Thomson Reuters has developed methods to parse such entries, since they also have well-established mechanisms for harvesting proper (data) references from the reference list.

All the ontological terms required to mark up in-text reference pointers and their textual contexts, references, reference lists, etc., to permit automated detection and harvesting of data citations and references, are available as RDF within the SPAR (Semantic Publishing and Referencing) Ontologies (http://purl.org/spar/), which were designed precisely to facilitate such work.

Since writing my Data Citation Best Practice Discussion Document, I was invited (on a purely voluntary non-commercial basis, I should add!) to work with Pensoft Journals, a publisher that specialises in publishing biodiversity and biological systematics papers, and that has taken the lead in promoting the publication of datasets with DOIs, to contribute to and help revise their now-published Data Publishing Policies and Guidelines for Biodiversity Data [4]. This 34-page paper has a three-page section on how to cite data in Pensoft Journals, which I discuss in the next blog post, and which I am pleased to say includes all the recommendations discussed above.

[1] David Shotton (2011) Data Citation Best Practice Discussion Document. Google Docs. https://docs.google.com/document/d/1kF8-faB72l4dKTLEyx6Z5cIabk68GrJ9GraCtWnK0qQ/edit?hl=en_GB&authkey=CPPW46wL#.

[2] The DataCite Metadata Kernel version 2.0 (2011). http://datacite.org/schema/DataCite-MetadataKernel_v2.0.pdf.

[3] Micah Altman and Gary King (2007). A proposed standard for the scholarly citation of quantitative data. D-Lib Magazine. 13. http://www.dlib.org/dlib/march07/altman/03altman.html.

[4] Penev L, Mietchen D, Chavan V, Hagedorn G, Remsen D, Smith V, Shotton D (2011). Pensoft Data Publishing Policies and Guidelines for Biodiversity Data. Pensoft Publishers, http://www.pensoft.net/J_FILES/Pensoft_Data_Publishing_Policies_and_Guidelines.pdf.

Questions of granularity – Dryad’s use of DataCite DOIs for data citation, and the Annotation Ontology

DataCite is an international organisation, founded in 2009, which promotes the use of DOIs (Digital Object Identifiers) for published datasets, in order to establish easier access to research data, to increase acceptance of research data as legitimate contributions in the scholarly record, and to support data archiving to permit results to be verified and re-purposed for future study.

Its founding members were the British Library; the Technical Information Center of Denmark; TU Delft Library; the National Research Council’s Canada Institute for Scientific and Technical Information (NRC-CISTI); California Digital Library; Purdue University; and the German National Library of Science and Technology. Since its foundation, it has been joined by several other leading organisations from around the world, and it therefore provides a stable basis for the ongoing use of DOIs for data.

This recent availability of DOIs from DataCite for the identification of data entities has made all the difference to data repositories wishing to give unique global identifiers to their data holdings, since DOIs are widely recognised and respected throughout the academic world, because of their widespread prior use for identifying journal articles, made possible by CrossRef.

However, in their recent discussion paper Data Citation and Linking, published on 8th June 2011, Alex Ball and Monica Duke of UKOLN at the University of Bath ask:

“At what granularity should data be made citable? If single datasets are given identifiers, what about collections of datasets, or subsets of data?”

Individual data files and metadata documents will, of course, have their own unique internal identifiers within any data repository, but may not have externally resolvable identifiers such as DOIs. Practice varies.

This post is to explain how DOIs are employed in the Dryad Data Repository, that specializes in publishing data linked to peer-reviewed biological journal articles, since it is both elegant and addresses at least some of the issues raised by Alex and Monica.

The Dryad DOI usage policy is described at https://www.nescent.org/wg_dryad/DOI_Usage, and involves assigning unique DOIs to each version of every data package, and to each version of every data file, in a principled and easy-to-understand manner. In summary:

Each data package is given a DataCite DOI, which can be versioned by adding “.2”, “.3”, etc. after the original DOI to create new DOIs for new versions of the same data package.

Within each data package, each data file has a unique DOI defines by suffixing the data package DOI with “/1”, “/2”. etc., with versions indicated as for data packages.

Thus the third version of the second data file in the second version of a Dryad data package would have a DOI of the form doi:10.5061/dryad.1234.2/2.3.

One might argue that it would result in an awfully large number of DOIs if a single data package was made up of thousands of data files. True, but numbers themselves are limitless and free, and the cost of a DataCite DOI is small relative to the cost of data creation and preservation. The real problem at present is lack of identifiable, citable data entities within repositories – to have so many that the cost of DOIs becomes an issue should be regarded as an achievement, not a problem!

Dryad does not have a mechanism for assigning identifiers to a portion of a data file (“a subset of data”), and DOIs are probably not the correct identifiers for that purpose, since they are primarily designed for citation and resource discovery.

A more appropriate method for identifying portions of a data file, or of any other digital object or document, is to use the Annotation Ontology (AO) developed by Paolo Ciccarese of Harvard University, described at http://code.google.com/p/annotation-ontology/wiki/Homepage. AO can be used to identify and annotate portions of a wide variety of resources such as HTML, PDF, Word, Excel, XML documents, images, videos, databases, web services, experimental data and metadata files. Paolo is currently working with a group in Harvard that focuses on biodiversity, who are using OA to address databases and data, and he anticipates publishing version 2.0 of AO in September.

Nomenclature for data publications and citations

The meaning of the word “dataset” is ambiguous, changing with context. In FaBiO , the FRBR-aligned bibliographic ontology, we define “dataset” at the conceptual level (i.e. as a frbr:Work) thus:

fabio:Dataset: “A collection of related facts, often expressed in numerical form and encoded in a defined structure.”

In situations demanding precision in terminology, such as data repository metadata and data citation, I think it is wiser to avoid the use of the term “dataset”, and instead to use the terms “data file” and “data package“, as the entities that data repositories handle and to which identifiers pertain.

In FaBiO, a data file is defined as follows:

fabio:DataFile: “A realisation of a fabio:Dataset (a frbr:Work) containing a defined collection of data with specific content and possibly with a specific version number, that can be embodied as a fabio:Digital Manifestation (a frbr:Manifestation with a specific format) and represented by a specific fabio:ComputerFile (a frbr:Item) on someone’s hard drive.”

FaBiO also has the class

fabio:MetadataDocument “A document that contains metadata information describing one or more characteristics of an entity”, which is a realization of fabio:Metadata
“A separate work that provides information describing one or more characteristics of a resource or entity”.

Using ORE, a data package containing data files and a metadata manifest can be defined as type of ore:Aggregation. However, ORE is not sufficiently expressive to meet the need of repositories who may wish to refer specifically to data packages, to manifests and to the landing pages displaying metadata relating to data packages and individual data files in their RDF metadata. For this reason, we have developed two tiny new ontologies, DaPO, the Data Package Ontology, and LaPO, the Landing Page Ontology, that provide the missing nomenclature, as will be detailed in a future blog post.

DataCite2RDF – Mapping DataCite Metadata Scheme Terms to ontologies

The DataCite Metadata Kernel version 2.0 [1] specifies the minimal metadata, and optional metadata, that should accompany a DataCite DOI for the identification of a published data entity. Within the Metadata Kernel document there is an XML mapping of these metadata terms, using DCMI Metadata Terms, and an example encoded in XML.

Silvio Peroni and I recently published a mapping of the DataCite metadata elements to RDF using ontology terms [2], in order to enable data repositories to publish DataCite metadata in RDF as Open Linked Data, enabling these metadata to be understood programmatically and integrated automatically with similar data from elsewhere.

Our mapping covers all the main terms, and the Relation Type sub-properties that describe the relationship of the related resource to the resource being registered, but does not address DataCite sub-terms, e.g. 2.2.1 nameIdentifierScheme.

Wherever possible, commonly used Dublin Core Elements, DCMI (Dublin Core Metadata Initiative) Metadata Terms, FOAF (Friend of a Friend Vocabulary) and PRISM (Publishing Requirements for Industry Standard Metadata) terms have been used.

These have been supplemented, as appropriate, by terms:

from FRBR (Functional Requirements for Bibliographic Records),

from the following SPAR (Semantic Publishing and Referencing) Ontologies:

CiTO, Citation Typing Ontology

FaBiO, FRBR-aligned Bibliographic Ontology, and

CiTO4Data, an extension of CiTO for datasets that provides the properties cito4data:compiles and cito4data:isCompiledBy that the DataCite Metadata Kernel requires;

and from a new DataCite Ontology (http://purl.org/spar/datacite/) that we created to provide the following four object properties lacking in other Ontologies:

datacite:hasPrimaryIdentifier

datacite:hasAlternateIdentifier

datacite:hasRelatedIdentifier

datacite:hasPersonalIdentifier

Use of DCMI Metadata Terms in RDF

An object property has a class or a URI as its object, while a data property has a literal (e.g. text, number, date) as its object, and may have a W3C XML Schema Definition Language (XSD) datatype qualifier, e.g. ^^xsd:date. (See http://www.w3.org/TR/xmlschema11-2/).

Many Dublin Core properties are not formally specified to be one or another, leading to potential confusion. In the following mapping, Dublin Core Elements are always used as data properties, while Dublin Core Metadata Initiative Metadata Terms are used either as data properties or as object properties, as helpfully specified by the Max Planck Digital Library in their document entitled How to use DCMI Metadata as linked data.

In our DataCite2RDF mapping document [2], alternative mappings are given where appropriate, separated by semi-colons. Both dc: and dcterms: properties are listed. Preferred terms are shown bold. RDF statements are given in Turtle notation.

Accompanying this DataCite2RDF mapping document, we published as Google docs both an RDF mapping of the DataCite XML example, and an RDF mapping of the metadata for a Dryad repository holding, showing how DataCite2RDF can be used for real data.

We welcome feedback on these documents: <david.shotton@zoo.ox.ac.uk> and <speroni@cs.unibo.it>.

[1] The DataCite Metadata Kernel version 2.0 (2011). http://datacite.org/schema/DataCite-MetadataKernel_v2.0.pdf.

[2] David Shotton and Silvio Peroni (2011). Mapping DataCite Metadata Scheme Terms (v2.0) to ontologies (DataCite2RDF). Google docs. https://docs.google.com/document/d/1paJgvmCMu3pbM4in6PjWAKO0gP-6ultii3DWQslygq4/edit?authkey=CMeV3tgF&hl=en_GB.

Using FaBiO to describe data entities

In addition to using CiTO and CiTO4Data to describe relationships of relevance to data entities, as discussed in the previous blog post, FaBiO, the FRBR aligned Bibliographic Ontology described elsewhere, another member of the suite of SPAR (Semantic Publishing and Referencing) Ontologies, also has a number of classes and properties specifically designed for addressing data, software, metadata and other non-bibliographic entities. The purpose of this short post is simply to list these in one place.

Sub-classes of fabio:Work

fabio:ControlledVocabulary, sub-class of fabio:Vocabulary, with sub-classes

fabio:AuthorityFile

fabio:Ontology

fabio:Taxonomy

fabio:Thesaurus

fabio:Dataset

fabio:Image, with sub-classes

fabio:MovingImage

fabio:StillImage

fabio:Metadata, with sub-classes

fabio:ApplicationProfile

fabio:BibliographicMetadata

fabio:CitationMetadata

fabio:EntityMetadata

fabio:ProjectMetadata

fabio:Model

fabio:Specification, with sub-classes

fabio:Algorithm

fabio:VocabularyMapping

fabio:Workflow among others

fabio:SoundRecording

Sub-classes of fabio:Expression

fabio:ComputerProgram

fabio:DataFile

fabio:DataBase, with sub-classes

fabio:RelationsDataBase

fabio:Triplestore among others

fabio:DataRepository

fabio:Figure

fabio:MetadataDocument

fabio:Movie, with sub-class

fabio:Film

fabio:Repository, with sub-classes

fabio:DataRepository

fabio:DocumentRepository

fabio:WebArchive

fabio:Spreadsheet

fabio:SupplementaryInformationFile

fabio:Table

fabio:VocabularyDocument, with sub-class

fabio:OntologyDocument

Sub-classes of fabio:Manifestation

fabio:DigitalManifestation

Sub-classes of fabio:Item

fabio:DigitalItem, with sub-class

fabio:ComputerFile

Object properties

fabio:stores, and its inverse fabio:isStoredOn

Data properties

fabio:hasDepositDate

fabio:hasEmbargoDate

prism:versionIdentifier

/end

CiTO4Data – a new data-centric citation typing ontology

This is the first of a series of blog posts on the Open Citations blog that address the problem of citing data entities, for example a data package in a data repository, rather than bibliographic entities such as journal articles. For these purposes, the existence of DataCite to assign DOIs to datasets, and extensions to the SPAR (Semantic Publishing and Referencing) Ontologies to handle data items, are both important. This post addresses the second of these two issues.

As described in the previous blog post, CiTO, the Citation Typing Ontology, focuses on providing ontological properties to characterize citations of bibliographic entities. However, several of its relationships can also be used in relation to data entities:

Sub-classes of cito:cites

cito:citesAsDataSource

cito:citesAsEvidence

cito:corrects

cito:extends

cito:updates

cito:usesDataFrom

When attempting to map the DataCite metadata elements to ontology terms, to be described in a subsequent blog post, we encountered the DataCite requirement for the properties compiles and isCompiledBy, which are absent from CiTO and other ontologies that we know about and which cannot be conceived as relating to bibliographic entities.

Conscious of a growing need to specify metadata for data entities as well as bibliographic entities, and reluctant to include in CiTO relationships that cannot be applied to bibliographic entities, Silvio Peroni and I have thus created CiTO4Data, a new ontology within the SPAR ontology suite, to be found at http://purl.org/spar/cito4data/.

CiTO4Data, the Citation Typing Ontology for Data, is an extension ontology written in OWL 2 DL that imports CiTO, the Citation Typing Ontology, and adds extra object properties that are relevant only for datasets, computer programs and other similar digital objects, but not for conventional bibliographic entities.

To date, CiTO4Data adds just a single new object property

cito4data:compiles

and its inverse

cito4data:isCompiledBy

created to meet the need of encoding the DataCite Metadata Kernel v2.0 into RDF. We intend to expand CiTO4Data to include other properties relevant only for citing data entities, as the need arises.

NOTE: In the summer of 2012, we decided for simplicity to include these two properties within CiTO itself (as cito:compiles and cito:isCompiledBy), and to deprecate the CiTO4Data ontology.

BIBO2SPAR, an RDF Mapping of BIBO to the SPAR Ontologies

In the previous blog post, I made a textual comparison between BIBO v1.3, the Bibliographic Ontology developed by Bruce D’Arcus and Frédérick Giasson, and FaBiO, the FRBR-aligned Bibliographic Ontology.

In this post, I wish to introduce our RDF mapping of BIBO (version 1.3, undated, downloaded from http://purl.org/ontology/bibo/) to the SPAR (Semantic Publishing and Referencing) Ontologies, particularly to FaBiO (version 1.1, dated 23-06-2011, downloadable from http://purl.org/spar/fabio/), to permit cross-walk between these two systems.

The mapping takes the form of an alphabetical listing of all BIBO classes, object properties and data properties, for each of which is provided a SKOS mapping to equivalent classes, object properties or data properties in FaBiO or one of the other SPAR ontologies, or to relevant terms in FRBR, PRISM, FOAF, SKOS or Dublin Core Metadata Initiative Terms, where such a mapping is possible. Where it is not, a note is included to explain why.

Note that most of the classes in FaBiO are arranged according to the FRBR data model into fabio:Works (69 sub-classes), fabio:Expressions (92 sub-classes), fabio:Manifestations (10 sub-classes) and fabio:Items (4 sub-classes). 38 of the BIBO classes are sub-classes of bibo:Document, which roughly corresponds to fabio:Expression.

Note also that, because of the ambiguity and multiplicity of meanings of the word “document”, FaBiO intentionally lacks the class fabio:Document, using instead the generic term fabio:Expression and more specific sub-classes. In contrast, BIBO classifies things as diverse as films, slideshows and web pages as sub-classes of bibo:Document.

Note further that BIBO contains classes that describe social events, such as bibo:Interview and bibo:Performance, and that describe specific legal documents such as bibo:LegalDecision and bibo:Legislation. These have no equivalents in the SPAR Ontologies.

The mapping document, BIBO2SPAR, is written as validated RDF in Turtle format, and is available at https://sempublishing.svn.sourceforge.net/svnroot/sempublishing/SPAR/BIBO2SPAR.ttl

In the mappings, the BIBO class or property name is given on the left of each line, followed by the SKOS mapping relationship and the equivalent class or property name used in the SPAR ontologies, e.g.

bibo:AudioDocument skos:exactMatch fabio:AudioDocument .

This mapping document has been prepared by and is copyright © David Shotton, University of Oxford, and Silvio Peroni, University of Bologna, 23 June 2011, and is published as open data under a Creative Commons 2.5 attribution license.

Please contact <david.shotton@zoo.ox.ac.uk> or <speroni@cs.unibo.it> for further information.

Comparison of BIBO and FaBiO

BIBO v1.3, the Bibliographic Ontology developed by Bruce D’Arcus and Frédérick Giasson [1], was the first OWL ontology dedicated to describing bibliographic entities, and has attracted a wide group of users. It provided the much-needed ability to describe the nature of cited works in RDF to a high degree of granularity, in terms of Title, Abstract, Journal, Volume, Pages, ISSN, DOI, dataCopyrighted, editor, etc.

FaBiO, the FRBR-aligned Bibliographic Ontology, which was created more recently and was introduced in a previous blog post [2], bears many similarities with BIBO, including its overall scope and intention, and the inclusion of PRISM and DC Terms data properties. A clear comparison of these two ontologies, and the provision of a mapping between them, is long overdue.

The primary differences between FaBiO and BIBO are as follows:

While BIBO is a ‘flat’ ontology, FaBiO is structured according to the FRBR conceptual model, in which publication entities are described from four different and correlated points of view, those of Work, Expression, Manifestation and Item, each of which is a FRBR Endeavour, as defined in a previous blog post. This structure has been introduced to provide greater expressivity. For example, using FaBiO one can describe a fabio:ResearchPaper that can be published as a fabio:JournalArticle, or alternatively as a fabio:ConferencePaper or a fabio:BookChapter. BIBO has the class bibo:AcademicArticle, which conflated the two concepts ResearchPaper (a conceptual Work) and JournalArticle (an Expression of that Work).
Great care has been taken to make the textual definitions of FaBiO classes accurate and expressive. Thus, while BIBO’s definition of bibo:Standard is “A document describing a standard”, FaBiO describes fabio:TechnicalStandard, which is a subclass of fabio:Specification, as “An official or public specification of, or requirement for, a technical method, practice, process or protocol that is involved in, for example, manufacturing, computation, electronic communication, or digital media.”
FaBiO is larger than BIBO (211 rather than 69 classes, 69 rather than 52 object properties, 45 rather than 54 data properties, and 16 rather than 15 individuals), permitting greater expressivity.
BIBO has a slight subject specialism in the area of legal documents (including bibo:Bill, bibo:Brief, bibo:CourtReporter, bibo:LegalCaseDocument, bibo:Statue). In addition to covering conventional scholarly works, BIBO also covers a few things outside the immediate realm of bibliographic entities, including social events (e.g. bibo:Hearing, bibo:Interview, bibo:Performance) and personal roles (e.g. bibo:interviewer, bibo:performer, bibo:producer). In contrast, FaBiO was developed to describe anything a research scientist might need to reference. Thus it lacks legal classes but includes classes that betray a preoccupation with academia and publications (e.g. fabio:ExaminationPaper, fabio:Preprint, fabio:SupplementaryInformationFile), funding and IPR (e.g. fabio:GrantApplication, fabio:PatentApplication), biomedical research (e.g. fabio:ClinicalTrialDesign, fabio:SystematicReview), research data (e.g. fabio:Dataset, fabio:Metadata, fabio:DataBase, fabio:DataRepository), computing (e.g. fabio:Algorithm, fabio:ComputerProgram), web communication (e.g. fabio:BlogPost, fabio:WikiEntry) and ontologies (e.g. fabio:ControlledVocabulary, fabio:Ontology, fabio:Thesaurus, fabio:Taxonomy), none of which are present in BIBO.
FaBiO is not a stand-alone ontology, but is one of the SPAR (Semantic Publishing and Referencing) Ontologies, a suite of complementary and orthogonal ontologies outlined in two previous blog posts [2, 3], that cover all aspects of publishing, referencing and bibliographic endeavour.
FaBiO and the other SPAR ontologies are written in OWL 2 DL, enabling them to be used in the Semantic Web with appropriate reasoners. In contrast, BIBO is in OWL Full, since it includes the RDF resources rdf:List, rdf:Seq and rdfs:Resource and the property rdf:value that cannot be included in proper OWL2 DL ontologies.
BIBO contains a few elements that are not present within FaBiO, but that have equivalent elements within some of the other SPAR ontologies:
1. the object properties bibo:cites and bibo:isCitedBy have equivalent properties in CiTO, the Citation Typing Ontology, where they have 32 sub-properties lacking in BIBO;
2. classes to describe component parts of documents (e.g. bibo:DocumentPart) that are covered in DoCO, the Document Components Ontology;
3. classes and properties to describe the status of documents (e.g. bibo:DocumentStatus, bibo:status), that are covered in PSO, the Publication Status Ontology.
FaBiO and CiTO have been harmonized [4] with the SWAN (Semantic Web Applications in Neuromedicine) ontology ecosystem developed by Tim Clark and Paolo Ciccarese of Harvard University, which covers the domain of scientific discourse in general, with particular application to neuromedicine, and which is used particularly useful for characterizing rhetorical structures between documents. Since SWAN had been previously harmonized with the SIOC (Semantically-Interlinked Online Communities) ontology for describing blogs, wikis and discussion groups, this provides the basis of a powerful new web framework for scientific communications.
For categorising bibliographic resources, FaBiO has been integrated with and extends SKOS, the Simple Knowledge Organization System [5] that supports the use of thesauri, classification schemes, subject heading lists, taxonomies and other knowledge organization systems within the framework of the Semantic Web, as described in a previous blog post.

The choice of whether to use BIBO or FaBiO depends upon whether BIBO possesses sufficient expressiveness for the task in hand, whether the user is prepared to put in the small degree of extra effort required to engage with the layered FRBR structure of FaBiO rather than the flat structure of BIBO, whether one requires the semantic reasoning support of an OWL 2 DL ontology, and whether the user requires integration with other ontologies such as CiTO and SWAN, that FaBiO provides.

To assist existing users of BIBO and the SPAR Ontologies to map between these two systems, we have used SKOS to prepare an RDF mapping document, BIBO2SPAR, that we describe in the following blog post.

[1] Bruce D’Arcus and Frédérick Giasson (2009). Bibliographic Ontology Specification. Specification Document, 4 November 2009. http://bibliontology.com/specification.

[2] David Shotton (2010) Introducing the Semantic Publishing and Referencing (SPAR) Ontologies. JISC Open Citations Blog, 14 October 2010. https://opencitations.hypotheses.org/16.

[3] David Shotton (2011) New web site for the SPAR ontologies. JISC Open Citations Blog, 25 February 2011. https://opencitations.hypotheses.org/55.

[4] Ciccarese P, Shotton D, Peroni S and Clark T (2011) CiTO + SWAN: The Web Semantics of Bibliographic Records, Citations, Evidence and Discourse Relationships. (Submitted for publication).

[5] Miles, A., Bechhofer, S. (2009). SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009. World Wide Web Consortium. http://www.w3.org/TR/2009/REC-skos-reference-20090818/.