Research Data Access and Preservation Summit, 2016 Atlanta, GA May 4-7, 2016 Poster session (Wednesday, May 4) Presenters: Simon Porter, Digital Science Dan Valen, figshare

1. Results
Getting RDF from a figshare record using figmeta:
52.19.173.139:8082/figjson-ld?
article_id=3079975&format=json-ld
Hacking the figshare API to Create Enhanced Metadata Records
Background
This poster will showcase a proof of concept method for
marking up figshare records with enhanced RDF
metadata using the figshare API (docs.figshare.com)
Existing metadata requirements
At present, figshare mints all of its DOIs from DataCite
through the EZID service hosted at the California Digital
Library. In order to meet with DataCite metadata
conditions, figshare requires users to add the following
information before making files public and citable: Title,
author list (ordered), categories (set ontology), tags (free
text) and a description with as much context as needed to
interpret the files. Users can also add links to external
sources.
Institutional clients can define additional custom metadata
when implementing figshare.
RDF/JSON-LD:
The example we’ll highlight here will be to express
figshare records in RDF, including JSON-LD. We also
extended this work by using the same method to expose
figshare metadata + additional triples stored on the article
(additional metadata). All figshare API metadata is
exposed in JSON (JavaScript Object Notation).
Simon Porter – Digital Science | Dan Valen – figshare
Acknowledgments
This poster could not have been put together without the
determination and hack-happy brain of Simon Porter.
We’d also like to thank the figshare API team for their
hard work and feedback.
Conclusions
figshare attempts to keep the barrier to entry as low as
possible in regards to uploading and sharing metadata
and even automating metadata capture, but in order to
maximize reuse, researchers should maximize context.
This proof of concept shows that additional curation either
during the data capture, data publication, or post data
publication can occur to provide additional discoverability
and context around those data.
Aim
RDF + figshare
All figshare metadata records are currently exposed in
XML using the Dublin Core Schema. With these fun
enhancements, researchers, data curators, and librarians
are able to “hack” existing records to expose figshare
metadata in different schemas such as RDF, MODS, and
more.
Existing figshare DataCite record in XML:
Method
RDF and steps
By creating a standalone app “figmeta”, the curator is
able to edit private or “version” public records by
attaching a readme metadata record exposed as
metadata.json-ld
• In this example, figshare metadata is converted to
VIVO-ISF ontology (using the figshare API and RDFlib
Python library) -- This work was done in collaboration
with FORCE2016 and OpenVIVO
• Any other files in a figshare article that also contain
RDF are added to the graph
Updating a figshare record with RDF
• Post graph back to “figmeta” post in RDF/XML graph
(the template used here is from
http://rdforms.com/editors/dcat/)
• Triples not already stored in figshare API graph, are
stored in separate file against the figshare record:
metadata.json-ld
• metadataGraph = submittedGraph - figshareAPI graph
Step-by-step
The Thinking behind this
One of the challenges for the progression of research
metadata standards is that technology often gets in the
way. Ideally, this is not how things should be. The
adoption of standards and practices should be
community-led, with technology functioning as the
enabler. This work is one way use of figshare + RDF can
place the development of metadata standards in the
hands of the research community.
Credit for metadata form creation?
In the proof of concept, we used rdfoms, a JSON format
for creating forms that author RDF. We feel these forms
are also contributions to research, as they help define
what needs to be recorded. We uploaded them into
figshare so they could get credit too!
Users can request an API token directly from the figshare
GUI
All user data on figshare is now accessible in figmeta
figmeta then allows curators to add enhanced [mapped]
metadata and associate that metadata as a separate record
to the file. We used rdforms (rdforms.org) to facilitate RDF
data entry
The result is a record that exposes all content in a figshare
in RDF that maps to additional fields using the VIVO-ISF
ontology
A Community Collaboration
Working out the right way to express a figshare record as
RF would not have been possible without collaboration
with the VIVO and Force2016 community.
We are especially grateful to Mike Conlon, Project
Director VIVO, for making available the code that was
used to load figshare records into OpenVIVO from the
FORCE2016 figshare portal available on Github.