...
- Introductions (all)
- What is your current Fedora status?
- If you are not on F4, what are your migration/installation plans? What are your barriers?
- Clarify distinction between NonRdfSource and its Description as one repository resource or two LDP resources
- Example, what are the implications of event messaging from actions on either "resource"?
- Fedora API Specification
- Seeking initial agreement, followed by alignment of implementation to specification
- ModeShape5, backend databases, and migrations
- Atomicity in the Java kernel API
- Which methods on services and resource types are atomic and / or synchronous? This is going to matter to reimplementations that reuse the Java kernel API.)
- Local implementations and/or implementation ideas, issues? priorities? (open forum)
- ...
- <add topic here>
Minutes
API Specification
Versioning
- When looking at a version that is a version of an original, is there a link to the original version? Yes
- Most important thing is that a client understands if it a versioned resource or nor
- In the current implementation, if you look at a versioned resources, all links are to the snapshot version
- Can be crawled by an LDP client that has no awareness of versioning mechanism
- Links to resources in the version snapshot tree will be this way
- Links to resources outside the versioned snapshot tree are to non-snapshot URI
- So a client that is LDP-only client that is unaware of versioning semantics can escape the snapshot tree and not be aware of it
- The most consistent approach would be to link to canonical (current version URIs) always, have memento-aware client look for versions.
- Could implement this using JCR in place currently
- Representation of versioned resources and snapshots would be different
- Esme: I thought there was some way to set versioning policy
- Mike: That was thrown out a year ago
- 7.2.2 is the default behavior in Fedora right now
- 7.3.3 would be the least challenging to implement right now
- Andrew: How important are versioning to people right now
- Diego: We need them right now, everything is incremental
- Sometimes versions can be in application logic, leave it as a separate concern from the repository. May be dubious value to rely on repository versioning
- Different applications are going to have different notions of versioning. Some use cases may consider different versions to be different resources entirely.
- Definitely some strong use cases for versioning as it is currently implemented now (and proposed in the spec),
- "I need the ontology (resource in the repository) that matches its state at X time in history"
- If one deletes the original version of a versioned resource, what happens to the version history?
- Currently, If you version binary directly and delete it, you'll delete all versions. If you if you have a binary in a container and version the container, deleting the binary will not delete the link to the binary for versions of the binary that are linked by
- versions of the container (somebody please fact check and/or state this)
Batch Atomic
- Basic idea is to start a transaction, perform requests, COMMIT or rollback. There had been some talk about timeouts
- Use case for "timeout all transactions" e.g. scheduling a reboot
- One idea: Just say "Implementation may choose to cancel transactions for any reason" in spec, don't specify how to do it
- Use case - ability checkpointing/continuations. Complex process in atomic batch. Would like to define incremental points that can be rolled back and continued.
- Continuations/checkpointing is probably a concern not for the core
- Dan: At a general level, maybe batch atomic should not be a core concern of the repository at all. Definitely have use case for "everything, or nothing",
- Adam: Probably should be in core, because broader Fedora community has asked for it and paid for it
Authorization
- Assumption is that requests are pre-authenticated, Fedora is enforcing authorization
- Resource points to policy "I'm protected by this". Policy points to resource or class of resources that are protected by it.
- Mike Lynch couldn't figure out how to pass user attributes to Fedora in order to enact policy
- user principal, on-behalf-of header should be in request, it's configurable (but needs to be defined at build time). The task is for something to populate these headers.
- In an unreleased version, users can be strings or URIs. It will be in 4.6.
Fixity Checking
- On ingest, or on-demand via REST request. Can store fixity events in repository.
- How does it extend to other checksum algorithms?
- SHA-1 supported because we get it "for free"
- How do we specify how to specify a checksum?
- Ingest- a header. On-demand, in POST
- For huge files (video files) there is no spec for finer-grained checksums
- In the EU, checksums and signatures are indicated in an XML format, checked by external tools. Not sure if it's XML signature spec per se, but it's expressed in XML.
- External tool can schedule re-checking of resourcces
- When changed, a new signature file needs to be generated.
- Will/should fixity generate events picked up by audit?