...
- For the Data Conservancy Fedora 4 ticks alot of the boxes, but missing some things.
- Domain specific apis is one such thing
- Is there a way to update Fedora to support these domain specific APIs.
- Put forward this use-case. Like to get a sense about supporting this effort and if you like it, perhaps some donated wiki space for use cases and discussion. Get support from the community.
- Dissemination architecture, kind of analogus to what dissemenators where in Fc3 but for Fc4. A lot more usable and share-able.
- The general problem is the Data Conservancy (or it's clients??) wanted to extend Fedora's API, associated with resources.
- For example, Post a tar-gz to a resource and have it attached,
- To address these needs at a layer between Fedora and the outside world for addressing those concerns. Redirect traffic to this tool.
- Want to redistribute code to share these resources, and a "CMA" to reason about the options available on an resource.
- The Data Conservancy is already committed to be doing this anyways, want to see if this would fulfill the missing disseminators from Fc3 in Fc4.
- Stefano Cossu is also moving forward with their own implementation of a similar use case. Resolve whether resources from Sparql or Solr index, are properly referenced/controlled in the access control layer.
- Another possible use case could be having a content model being applied at the ingest process. If you have derivatives already created, upload a multi-form data and have it place content in appropriate containers based on content model.
- Part of the use case document touches on parts of the CMA, interested in whether defining content-models in Fedora 4 (these intersect).
- As far as ingesting content and having different actions occur based on a content model, is exactly what might belong in this layer.
- These actions exists outside the core and acts on resources internally. It would be advantageous to be able to distribute the capability by jumping the OSGi band layer and use something like Apache Karaf. One can imagine a Karaf features XML file which defines the necessary jars to implement these (actions). Within scope would be deciding what the convention to package up these resources in a usable package.
- Question: Is this something that will involve changes to core Fc4 code or is more akin to the PCDM community effort?
- This is meant to be a layer between Fc4 and the outside world, perhaps in an entirely different JVM container.
- Conceptually it would be a layer distinct from Fc4. This layer would be for anything "out of scope" for Fc4.
- It may operate as a service proxy. The change is to have a service model with the object to share these special actions.
- Andrew Woods: This would involve minimal changes to core code.
- Question: Would this work with Fc4 access controls right now?
- You can currently do Fc4 access control right now or shuffle that need up a layer and handle it before Fc4. Principles of the original request would (or would not) flow through to Fedora. The service layer might change the request.
- If you wanted to know a priori if when you invoked a service would you be able to actually complete the request. This service layer could need to know how Fc4 applies these authentication policies, perhaps the WebACL discussion would have some impact.
- At this stage of producing a sketch of this proposal it would be part of a future discussion.
- Question: Would this be a place to implement WebACL to authenticate across repositories?
- Yes, it is operating as a reverse proxy with a camel route which... if you can envision it, we can glue it in.
- Hoping to generate more use cases for this, that could definitely be one.
- Check out the initial use cases on the proposal document. These are data conservancy's use cases, if there are people in the community that are interested in this we would want to flesh out these use cases.
- Question: Could another use case be a IIIF image server?
- Yes and Johns Hopkins would be very interested in this.
- The idea would be to embrace OSGi, and things like Apache Karaf. The OAI-PMH provider specifically, then theoretically without having to worry about this layer. Deployment would be provided by OSGi framework.
- OSGi'"fying" Fedora core is a significant investment of time.
- This OSGi'ing could be external to Fedora, but there is a benefit to Fedora.
- OSGi is a standard for including additional information in Jar files such that packages could be hot-deployed. A means of packaging up. Smart class loaders in Java, allows this hot-deployment of services and technology. A technical framework.
This proposal would require Camel and the web apps in one framework and Fedora in another. To make a change, you would need to restart the container environment to make changes.
Karaf has a dynamic configuration framework, if I want to change the configuration file, the second I change the file it will auto-redeploy the appropriate routes. OSGi defines this lifecycle and the Karaf manages the lifecycle.
This has no actual impact on Fedora core, other than the idea of OSGi layers. To understand what is in scope of Fedora and what should go external. - Question: What support for OSGi in service providers, is there such support?
- Unsure of the level of support.
- Do we see a reason not to support this effort? No objections.
- What would be the most useful or helpful ways to rallying support as the data conservancy will be implementing this framework anyways. Get the document out to the community and schedule some calls to get some use cases. A wiki page to coalesce the ideas and discussion.
- Need to work out a timeline. First step is to put the document out to the community in general, and see what the uptake on it it. If people are interested in the layer, then figure out how.
- Very important feature to Art Institute of Chicago that they are implementing their own.
- Question: What about Hydra or a middle layer?
- That would need to be sketched out, defining who is interacting with whom and where certain functionality lives. Perhaps there are services written in Java that does something and maybe Hydra uses that. There are many options that would need to be sorted out.
- The Data Conservancy are interested in Blacklight and maintaining an index of these resources which could be maintained by this layer.
- Data validation could be dealt with in Hydra or at this layer.
| Anchor | ||||
|---|---|---|---|---|
|
- If you have a binary resource in Fc4, there is an associated resource that describes the binary datastream. Currently it is the binary URL + /fcr:metadata. We are moving towards a rule within the repository and you get the RDF that describes it, that the subjects in that RDF is the resource and not resource + /fcr:metadata. So this breaks the convention as some are fcr:metadata and some are the actual resource.
- Would it be possible to get rid of fcr:metadata and use content-negotiation. If you ask for an RDF format you get the RDF description and if you ask for JPG you get the binary back??
- An attractive end-goal is keeping fcr:metadata where everything you get back is all source or fcr:metadata.
- If you have an arbitrary RDF datastream and want to add it to the repository. You need to define a different content-type (other than application/rdf+xml).
- How do you define what resource describes "me"? It could be simple, but if not it could be very weird (Unknown User (escowles@ucsd.edu)).
- What would the binary be in an LDP sense? An LDP-NR and LDP-RS? Unless we default to either all binary or all RDF.
- With Marmotta, how does it deal with binary resources and their descriptions? The interaction pattern is that everything is a container. We are harvesting metadata container from providers, an LDP-RS gets created at the URI. Marmotta tries to guess the type and then appends the extension to the datastream. When you get the content with the suffix and description without.
- Interim step of single subject'izing. What is appropriate subject?
- the non-RDF resource, as this makes more sense.
- except administrative metadata, which is in fcr:metadata. That might be useful. But makes it a first-class resource itself.
- Do we have the last modified date separate from the binary? We don't think so.
- Is the last modified date of the fcr:metadata relevant? People might be storing information in the fcr:metadata and so having last modified date to determine changes to this might be in use, if not a mistaken implementation.
- Is fcr:metadata just another metadata container that can be attached or linked to the binary object.
- If fcr:metadata did not exist and I had a binary stream. How would I describe that binary. Opaque RDF would be how to do that.
- Could the solution be to have multiple properties, some reference the metadata around the binary and some reference the content of the binary.
- Use two different predicates, in this case.
...