RDF Working Session - Q3 Partner Meeting - 9/17/2013

Samvera Community Wiki


RDF Working Session - Q3 Partner Meeting - 9/17/2013

Fedora 4 - Hydra involvement - RDF Implication

RDF

  • Hydra seems to migrating to RDF both in terms of metadata representation and object representation

    • What are the opportunities going forward

      • Can we move to RDF as the native storage for metadata?

      • How do we structure objects via RDF?

  • Approaches

    • Metadata first

      • Metadata standards vary

      • Metadata standards evolve

    • UCSD

      • Use RDF as a flexible way to accommodate this variability

      • Do store serialized version in repo for preservation purposes

      • Use Solr for real-time discovery (rather than underlying triple-store)

      • New collection and object types present new engineering challenges each time

    • Penn State

      • Uses RDF for back-end storage

      • Uses Dublin core (plus some other vocabularies) as inspiration for user presentation

      • ActiveFedora didn't initially have current RDF support - would have used current capabilities if they had existed at the time

  • Action Items

    • Start RDF in Hydra hub on the wiki

      • Start to capture object representation for specific content types (i.e. image, book, etd, etc.)

    • Review Matt Z's initial docs, update, and add to RDF hub

    • Find time and space at next Hydra meeting to do in-person collaboration on data modeling

      • Initiate Hydra RDF working group!

      • Prior to Q4 Partners?

    • Connect with Simeon Warner - Cornell - re: active triples

    • Identify what tooling is needed to flesh out RDF capabilites

      • Export transforms: RDF --> specific schemas

      • Import transforms: specific schemas --> RDF

      • Locate, invent, and share predicates (either a tool or some documentation)

      • Harvest, index, and link to vocabularies/authorities

      • Store URIs and surface strings (maybe a pattern worth documenting rather than a tool)

      • More efficient, "better"  querying of the graph (maybe needed?)

    • Identify how to expose necessary information from objects to properly display/export/manage them...