1. A Data API
with Security and
Graph-level Access Control
Dr. Barry Norton,
Development Manager, ResearchSpace*
The British Museum
* supported by the Andrew W. Mellon Foundation
ESWC,
Crete
May 2014

2. Open Endpoint
• “The idea that an enterprise would allow a public
SQL interface is laughable”
• True, but furthermore:
• The idea that an enterprise would allow
unrestricted SQL (even querying, let alone
update) is also laughable

3. Reality
• In reality the enterprise:
• runs an active directory service
• assigns permissions to databases using this
• assign read/write permissions to tables using this
• allows third-party software providers access only
to pre-defined queries and updates

4. Admission
• This talk is of low originality and negligible
scientific value!

5. State of the Art
• Some triplestores already provide graph-level access control
• The Datalift project produced a query-rewriting system to
provide access control over arbitrary triplestores (Costabello
et al., ECAI2012)
• Knud and Leigh, formerly of Talis, already presented how
Kasabi allowed pre-defined parameterised SPARQL queries
(WWW2012)
• The BBC, and other enterprises that have followed their
example, already use a similar approach in practice (see
presentations of Jem Rayfield)

6. State of the Art
• Some triplestores already provide graph-level access control
• The Datalift project produced a query-rewriting system to
provide access control over arbitrary triplestores (Costabello
et al., ECAI2012)
• Knud and Leigh, formerly of Talis, already presented how
Kasabi allowed pre-defined parameterised SPARQL queries
(WWW2012)
• The BBC, and other enterprises that have followed their
example, already use a similar approach in practice (see
presentations of Jem Rayfield)
Proprietary
Enumerates graphs in query
Dead !
(and proprietary user management)
Closed source

7. BM Dataset
http://collection.britishmuseum.org

8. Approach (1/4)

9. Approach (2/4)

10. Approach (3/4)

11. Approach (4/4)
• RESTful API for management of queries and updates (i.e. each such
becomes a URI-identified resource)
• Each query/update
• Can be parameterised (by POSTing parameters with XSD datatypes that
substitute for variables)
• Can be executed (subject to access and rewriting) by POSTing parameter
values
• Can be scheduled for execution by POSTing a schedule
• Can be tested, on schedule, by POSTing an XPATH or SPARQL ASK query
• Provides a GETtable resource per scheduled execution

12. ResearchSpace
• a reusable set of Linked Data-based components, making up
• a platform that allows researchers to make claims (additions and changes to
GLAM data) -
• that preserves and aggregates canonical data across Museums (LAMs),
• attributes claims,
• records arguments based on
• provenanced data annotation,
• image annotation
• forum-based discussion with explicit annotation
• will allow inference over claims

13. RS Search

14. Fundamental Relationships

15. RS (Conjunctive) Search

16. RS Data Annotation

17. Untrue claims?
• For years a (naive) objection to Linked Data has
been:
• “If I publish my data and give my things identifiers
(URIs), won’t people make untrue claims?”
!
!
<http://collection.britishmuseum.org/id/object/YCA62958>
crm:P52_has_current_owner
<http://semanticweb.org/id/Barry_Norton>

18. RS Image Annotation

19. RS ‘Data Basket’

20. RS Dashboard

21. Future Work
• Query rewriting currently uses the Jena parser,
want to re-implement using SPIN
• Rewrites become CONSTRUCT queries, rather
than code
• Make a publicly-accessible instance of the API so
people can publish parameterised queries and
schedule tests on endpoints