mapping – OpenCitations blog

Revising the DataCite2RDF mapping document

The purpose of mapping DataCite metadata elements to ontology terms is to enable DataCite metadata to be published in RDF as Open Linked Data, enabling these metadata to be understood programmatically and integrated automatically with similar data from elsewhere.

In the previous blog post, I described the updated and expanded version of the DataCite Ontology, version 0.6.1, that I created with Silvio Peroni to conform to the DataCite Metadata Kernel, v2.2 published in July 2012. The revised ontology now provides the eleven classes and five properties required to cover all the items in v2.2 of the DataCite Metadata Schema – not just the core DataCite metadata elements, but all of them – that were not conveniently covered by terms in other ontologies.

In this post, I describe how we have used this revised DataCite Ontology to create a new revised DataCite2RDF mapping document. This now replaces the previous mapping document, described in an earlier post, that was a partial mapping of the DataCite Metadata Kernel v2.0 using the original version of the DataCite Ontology.

Wherever possible in this new DataCite2RDF mapping, we have used commonly used vocabularies, including:

DCMI (Dublin Core Metadata Initiative),

FOAF (Friend of a Friend Vocabulary),

SKOS (Simple Knowledge Organization System), and

PRISM (Publishing Requirements for Industry Standard Metadata) terms,

supplemented by terms from FRBR (Functional Requirements for Bibliographic Records), and from the following SPAR (Semantic Publishing and Referencing) Ontologies:

CiTO, Citation Typing Ontology,

FaBiO, FRBR-aligned Bibliographic Ontology,

FRAPO, the Funding, Research Administration and Projects Ontology,

PRO, Publishing Roles Ontology,

SCORO, Scholarly Contributions and Roles Ontology, and, of course,

theDataCite Ontology itself.

The mapping document is structured in tabular form, with three columns: the first containing the DataCite ID, the second containing the name of the DataCite property, and the third containing the ontology entities used in mapping each of the DataCite metadata elements. All the metadata elements of the DataCite Metadata Kernel version 2.2 are included, both mandatory and optional, and both major and supplementary. For each, we provide not only the ontology terms, but also a specific exemplar of the usage of that term in an RDF statement, giving alternatives where appropriate. To show the style employed, the mappings for the first three DataCite metadata elements are shown in the following table:

ID	DataCite property	Equivalent ontology class or property
1	Identifier	datacite:PrimaryIdentifier (A sub-class of datacite:ResourceIdentifier that uses a datacite:IdentiferScheme that is restricted to datacite:doi, an individual in the datacite:ResourceIdentifierScheme)Exemplar usage: :my-dataset rdf:type fabio:Dataset ; datacite:hasIdentifier [ rdf:type datacite:PrimaryResourceIdentifier ; literal:hasLiteralValue "doi:10.1371/journal.pntd.0000228.g002.x001" ] .
1.1	IdentifierType	Restricted to datacite:doi, an individual in the datacite:ResourceIdentifierSchemeExemplar usage: :my-dataset rdf:type fabio:Dataset ; datacite:hasIdentifier [ rdf:type datacite:PrimaryResourceIdentifier ; literal:hasLiteralValue "doi:10.1371/journal.pntd.0000228.g002.x001" ; datacite:usesIdentifierScheme datacite:doi ] .
2	Creator	dc:creator (data property)Exemplar usage: :my-dataset rdf:type fabio:Dataset ; dc:creator "Shotton, David" . or dcterms:creator (object property) Exemplar usage: :my-dataset rdf:type fabio:Dataset ; dcterms:creator [rdf:type foaf:Person ; foaf:familyName "Shotton" ; foaf:givenName "David" ] .

To facilitate our mapping, the object properties compiles and isCompiledBy, that are required for the DataCite relationType controlled list, have now been included in version 2.2 of CiTO (created 3 July 2012) as cito:compiles and cito:isCompiledBy. The use of the mini-ontology CiTO4Data, that contained only those properties, has consequently been deprecated.

In several instances, we propose alternative mappings, depending upon whether one wishes to use a data property that has a literal (e.g. text, number, date) as its object, or to use an object property that has a URI as its object. As explained more fully in the mapping document itself, our recommended best practice is to use DCMI metadata terms (dcterms:) as object properties in preference over Dublin Core metadata elements (dc:) as data properties, unless one specifically needs to use a literal as the object of an RDF triple.

The new mapping document, DataCite2RDF, is available in PDF format from http://purl.org/spar/datacite/datacite2rdf.

A presentation related to this work, that was given at a DataCite meeting held at the British Library on 6 July 2012, is available here.

The next blog post describes a DataCite Metadata Input Form based on this new DataCite2RDF mapping that Tanya Gray and I have created. This is a Web input tool that permits easy entry of metadata compliant with the DataCite Metadata Kernel v2.2. The metadata can be saved in an XML file, and can be automatically mapped to RDF by employing an XSLT that uses this mapping.

We commend the use of this mapping to all who wish to encode DataCite metadata in RDF, and welcome feedback on this work.

David Shotton (david.shotton@zoo.ox.ac..uk)

Silvio Peroni (essepuntato@cs.unibo.it)

Revising the DataCite Ontology

In a previous blog post, I described the work that Silvio Peroni and I undertook in May 2011 to map the main terms from the DataCite Metadata Kernel v2.0 to RDF.

To enable that, we created a ‘proto-ontology’, the DataCite Ontology version 0.2, that contained just the following four object properties:

                    datacite:hasPrimaryIdentifier
                    datacite:hasAlternateIdentifier
                    datacite:hasRelatedIdentifier
                    datacite:hasPersonalIdentifier

These properties permitted us to provide identifier descriptions required by DataCite that could not be achieved using other Ontologies. We did this using the following type of construction:

:this-dataset datacite:hasPrimaryIdentifier
    [ a prism:doi ; literal:hasLiteralValue "***" ]  .

in which the object property relates to a blank node defining something that is a DOI and that has the particular literal value specified.

In July 2012, to permit an updating and expansion of the DataCite2RDF mapping, to conform to the DataCite Metadata Kernel, v2.2 published in July 2012, we undertook a complete revision of the DataCite Ontology to permit us to create mappings not just for the core DataCite metadata elements, but for them all.

As a result, the latest version of the DataCite Ontology, version 0.6.1, created on 18^th July 2012, now has 11 new classes and 5 new object properties, as shown in the following table:

Note that the four original specific object properties have been replaced by the single object property datacite:hasIdentifier, and that the method of defining the identifier has been changed. Now, rather than the object property relating to a blank node in which the identifier is defined as a literal, the object property datacite:hasIdentifier has as its object a member of the class datacite:Identifier, or of one of its three sub-classes, datacite:PersonalIdentifier, datacite:FunderIdentifier or datacite:ResourceIdentifier, as shown in the following diagram:

DataCite Ontology diagram — Diagrammatic representation of the DataCite Ontology version 0.6.1,
represented using Graffoo, a Graphical Framework For OWL Ontologies.

The exact nature of the identifier is then defined using the second DataCite object property datacite:usesIdentifierScheme that has as its object the class datacite:IdentifierScheme or one of its three sub-classes: datacite:PersonalIdentifierScheme, datacite:FunderIdentifierScheme or datacite:ResourceIdentifierScheme.

This provides a robust method for defining identifiers, since each specific identifier is defined as an individual member of its appropriate identifier scheme class. Using the new DataCite Ontology, these three types of identifier scheme can be used as follows:

:this-dataset a fabio:Dataset ;

  datacite:hasIdentifier [ a datacite:PrimaryResourceIdentifier ;
    literal:hasLiteralValue "XXX" ;
      datacite:usesIdentifierScheme datacite:doi ] ; 

  dcterms:creator [ a foaf:Person ; foaf:name "Smith, Jane" ;  
    datacite:hasIdentifier [a datacite:PersonalIdentifier ;
      literal:hasLiteralValue "YYY" ;
      datacite:usesIdentifierScheme datacite:orcid ] ] ;

  foaf:fundedBy [ a foaf:Organization ; foaf:name "Wellcome Trust" ;
    datacite:hasIdentifier [a datacite:FunderIdentifier ;
      literal:hasLiteralValue "ZZZ" ;
      datacite:usesIdentifierScheme datacite:fundref ] ] .

where datacite:doi is an individual member of the class datacite:ResourceIdentifierScheme specifying a DataCite Digital Object Identifier, datacite:orcid is an individual member of the class datacite:PersonalIdentifierScheme specifying an Open Researcher and Contributor Identifier, and datacite:fundref is an individual member of the class datacite:FunderIdentifierScheme specifying a FundRef Funder Identifier.

As need arises, new identifiers can be added later as new members of each class, without having to modify the structure of the DataCite Ontology. We have already added to the DataCite specification by adding three members, datacite:local-resource-identifier-scheme, datacite:local-personal-identifier-scheme and datacite:local-funder-identifier-scheme, to permit the use of local identifiers , and have requested that DataCite include such local identifier schemes in their next release (version 2.3) of the DataCite Metadata Kernel.

Version 2.2 of the DataCite Metadata Kernel has a property “Description”, with four permitted values: ‘abstract’, ‘other’, ‘series information’ and ‘table of content’. The DataCite team recognises that this rather rag-bag collection of values makes use of the Description property highly problematic, and has referred this matter to its metadata committee for re-consideration.

Nevertheless, to complete our development of the DataCite Ontology, thus permitting mapping of all the DataCite Metadata Kernel v2.2 metadata properties, we have created a new class, datacite:DescriptionType, and two final DataCite object properties, datacite:hasDescription and datacite:hasDescriptionType. These allows us to link an entity to another item representing an entity description of a particular type. This is defined using the property datacite:hasDescriptionType, which must have as its object one of the members of the class datacite:DescriptionType, i.e datacite:abstract, datacite:other, datacite:series-information and datacite:table-of-content. In this way it is possible to associate written documents (e.g. journal articles or ‘data articles’) as descriptions of datasets, as shown in the following excerpt:

:this-dataset a fabio:Dataset ;
    datacite:hasDescription [ a fabio:JournalArticle ;
    datacite:hasDescriptionType datacite:other ] .

We expect the membership of this class datacite:DescriptionType will expand once the DataCite Metadata Kernel v2.3 is published.

The following blog post describes the revised DataCite2RDF mapping created using this revised DataCite Ontology. We commend the use of this mapping to all who wish to encode DataCite metadata in RDF.

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.

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/.