Hydra:Works @ Code4Lib Notes
Hydra:Works @ Oregon Universtity
February 12th and 13th, 2015
——————————
HYDRA V. FEDORA
Question: Should this be data modeling be at the Hydra level or the Fedora level?
This data modeling would be useful for not just the Hydra community but the entire Fedora community and should exist outside of Hydra. The modeling should only include abstractions on relationship and not include functionality.
——————————
SUMMARY OF cMODEL
Our summary of the shared content model included a review of model diagrams created at the earlier meeting in Portland and the Application Profile Google Doc. We reviewed some of the basic assertions outlined in both documents as it relates to Works, Collections, and Files. We extended the conversation to include conversations about complex Use Cases that include descriptive or non-member works and how we should handle them. i.e. proxy nodes, donor agreements, terms of use, and thumbnails. Since Collections may not have hasFile and we want to distinguish between members and aggregates. This would be classified as ore:aggregates.
Collections
can have collections
can have member objects (works)
can have components
Use of predicate over subClassing: describes
Summary level of collection: hasMember
Works
Types of Works that Describe
thumbnail proxy
larger proxy
text proxy
Types of Works used for attaching a non-member work
Donor Agreement
Terms of Use
Thumbnail / Representative
Provenance / curatorial
----------------------------
Exemplary Record
Featured Record
Preferred Member
What do we do with these describe documents?
Since Collections may not have hasFile and we want to distinguish between members and aggregates. This would be classified as ore:aggregates
Assertion: Using works within works to encapsulate descriptive metadata for files provenance.
Complex Object Examples:
1. Scholarly Submission (Thesis - PDF, Dataset-CSV, Thumbnail - PNG)
Thesis (Work)
Dataset (Work)
Content (Work)
Thumbnail (File)
——————————
NAMING
We attempted to come up with a more representative name for our shared content model. The highlight on attempted. Although we couldn’t reach any consensus, there were some ideas thrown around with the most support for Object. Some the ideas included: Asset, Concern, Subject, Resource, FOB, DOB, Container, Object, and Entity. Prefix - Generic, Submitted, or Digital.
Should we stick with works?
What is the thing in Fedora: node, object, container,
Likes to standardizing on LDP
Fedora.info - Fedora namespace
——————————
LDP CONTAINERS
Rob Sanderson guided us through the W3 standard for linked data called LDP. The Linked Data Protocol could be used to organize our objects and data streams in Fedora4.
Here are two resources for LDP: alturl.com/b485n and www.w3.org/TR/ldp.
LDP is a platform for managing interactions of linked (RDF source) and non-linked data and containers. We discussed the use of basic, direct, and indirect containers to create a standard that would be manageable in Fedora 4 and linkable in RDF using REST and SPARKLE queries. The structure for writing these relationships to FEDORA 4 on works and files would be:
/works/1
/works/1/files
/works/1/files/f1
This structure will also work for the descriptive and non-member works
/works/1/files/
/works/1/membership/
/works/1/proxies/
and collections
/colls/1
/colls/2
/colls/1/membership/1
Algorithm for updating title
../works/
POST <dc:title"Fish"
../works/1
GET /works/1
/works/1 dc:title "Fish"
PUT /works/1
Topics to be discussed at LDCX:
Use of direct containers to automatically make assertions about newly created resources.
hasMembership Resource
hasFile: /works/1/files automatically
works/1 hasFile files/f1
There was agreement that this would be a good way to manage the objects, but we would need to check with Chris Beer and Andrew Woods to make that sure that Fedora 4 can handle LDP. Handle things like:
You can't change the e-tags when updating things.
What happens with reciprocal property?
What test need to write test?
——————————
INTERACTIONS
Should we have our own fedora convention for deleting resources?
Interact with REST / SPARQL
PATCH and PUTS (overwrite)
CREATE
Proposing
Membership using PATCH
ldp - structural metadata
very REST - SPARQL for metadata
——————————
ORDER
There was a little discussion around ordering efficiencies and RDF. There was still consensus around ORE ordering, but there were conversations around the use of serialized arrays, double linked list, and micro syntax in implementations.
Need a plan to implement ORE: There has been a big push since our return on the RDF Proxy List Repo: https://github.com/projecthydra-labs/rdf-proxy_list.
POST <> proxyIn Coll
proxyFor W
type ore:Proxy
——————————
HYDRA_WORKS
Once the decision was reached to treat this as a Fedora Content Model, we started to organize around the functionality that we would would like to make things more compatible with Hydra heads. The first point was that Active Fedora would need to be updated to use the LDP conventions. Then we started to model out SUFIA into works models. Concerns about where functionality should reside and how behavior should be implemented were also voiced. I think it remains unclear what will be in the Hydra:Works gem once the shared content model is in another FCDM gem.
Proposals:
submitted_resource to be used instead of generic_files?
one parent - one file?
hydra namespace to be used?
associations go in hydra:works?
Types of Hydra:Works:
leaf_work
How do i distinguish the leaf items?
Original
Thumbnail
Technical Metadata
use of file
predicate for indexing files in solr
leaf_works are defined by class
submitted_resource
How do i distinguish a submitted_resource?
compartments
How do i distinguish the compartment?
Where we will put this?
sufia_models
hydra:works
model/services/sufia - separate structure from behavior
Seperation of Concerns: Gem that represents data model structure and a gem that represents data model behavior.
What do we have to do in Active Triples?
Associations?
Persistence
Rules for removal
type and inheritance i
Active Fedora 9 will need changes to allow for ldp containers
indirect containers - should go into ActiveFedora
Add API that says I have a subcontainer at this place that should be direct or indirect
Active Fedora API wrappers around hydra:works
Build Abstractions up front
Timeframe for Hydra:Works including ordering: Mid-April
——————————
RDF CONCERNS
Topics for LDCX: A few RDF concerns were raised about namespacing, changing graphs, direct pointers, transcoding, and state.
——————————
ADMIN_SETS
Our LDP Structure for Admin Sets will resemble this:
admin/colls/1/membership
admin/works/1
admin/colls/2
Topics for discussion at LCDX:
Non-RDF Resources: File in Fedora is a non_rdf resource.
WebACL inheritance
Namespacing
Costly to move from one Admin Set to another with redirect.
Model… AdminSet can have class
——————————
ACCESS_CONTROLS
Needs to be discussed further.
Topics for LDCX:
How does this look in Hydra 9 and ActiveFedora 9?
WebACL has rdf representation of rights in Fedora
——————————
NEXT STEPS
The action items are:
1. Update Data Model Document (Rob, Esme, Tom, and Jon)
2. Coordinate with Fedora Works Repo (Thomas)
3. Other Metadata conversation (Karen)
4. Hydra:Tech on LDP containers (Rob)
5. Topics for LDCX - March 23