triple store interest group 2016.01.15

Owned by Anna Headley (Unlicensed)
Jan 15, 2016
2 min read

my own notes from the first meeting.

 

aaron coburn - amherst - sidecar triplestore

nabeeld - michigan - research data

trey - princeton - active fedora developer - has done extensive linked data work in the past

tom johnson - dpla - they use some hydra tooling with a triplestore already. nominally the maintainer of active triples and other related projects: rdf-ldp libraries, blazegraph repository ruby interfaces, rdf.rb 2.0 (adding an ACID transaction interface)

Mark matienzo - dpla - also has concerns around implementation w/r/t hydra-in-a-box. using active triples and LDP to manage metadata

hector - penn state - interested in what others are doing.

Adam wead - penn state - wanting to learn more.

penn at cornell - learning.

matt - ucsd - have had a variety of triplestore implementations. currently use a postgres triplestore backend but migrating to f4 and thinking about a sidecar triplestore as well. get a lot of request from metadata specials for running queries, metadata cleanup opportunities, etc. going to run a sparql workshop for their metadata folks.

christina - metadata workflows

justin - dce - lurking to see what everyone’s interested in doing

sheila - also lurking.

 

 

sidecar triplestore vs. linked data fragments

triple data fragments give sub, pred, object and return triples

goal: instead of that have a web interface where you give it a subject and it returns cached triples, then use an http API.

multiple implementations: one uses marmotta, one uses general RDF

2nd phase (yet to be done): sidecar indexer for atomic updates of linked data in SOLR.

 

hydra people talk more about importing linked data

fedora groups talk more about exporting triples from fedora to a triplestore. Use cases:

  • inferencing
  • using sparql for analytics - ad hoc queries across the data set in ways not possible w/ fedora or sold
  • validating integrity of triples

 

RDF Shapes working group has produced some validation language. fedora’s API-X group is also working on validations.

 

Access controls over a triplestore? Hydra does this well by controlling access to solr.

 

 

Tom J: 

  1. build community knowledge about which triple stores have various capabilities. get a sense of what people are able to use / who might maintain the various projects.
  2. gap analysis / development work on plugging this into the stack.

 

blazegraph: tom j. wrote the gem. it’s performant and good but if you use blank nodes they will duplicate!! user beware. also potentially trouble around quads.

 

marmotta 

 

jena / fuseki at scale (aaron coburn)

 

virtuoso - and attendant unmaintained gem.

 

apache rya