...
- A. Soroka
- Unknown User (acoburn)
- Michael Durbin
- Yinlin Chen
- Andrew Woods
- Osman Din
- David Wilcox
- Stefano Cossu
- Jon Roby
- Unknown User (escowles@ucsd.edu)
- Unknown User (daniel-dgi)
-
- James R. Griffin III
- Nick Ruest
- Jared Whiklo
- Benjamin Armintor
- Harshakumar UmmerpillaiDoron Shalvi
Agenda
- Open Repositories committer meeting reflections
fcr:metadata and NonRdfSource descriptions
Note of JCR Node structure
No Format NonRdfSourceDescription[JCR_NODE] | - FedoraBinary[JCR_NODE] | - datastream[JCR_PROPERTY]
- Questions on the table:
- Dealing with fcr:metadata:
- Should fcr:metadata, as an LDP-RS with a URI distinct from the LDP-NR, exist at all?
- If yes, should the contents of fcr:metadata be refactored such that all triples have only one subject?
- If yes, what should that subject be?
- If yes, Should fcr:metadata support the same kinds of operations that other repository resources support (such as DELETE or POST), or do only a subset of these pertain?
- If no, then should the binary contents of an NonRDFSource as well as its RDF description be available from the same URI, via content negotation? Is this consistent with letter and spirit of LDP?
- If yes, should the contents of fcr:metadata be refactored such that all triples have only one subject?
- Should fcr:metadata, as an LDP-RS with a URI distinct from the LDP-NR, exist at all?
- Dealing with Fedora resources, created by a user, to describe NonRDFSources:
- Should Fedora allow users to modify iana:describes/iana:isDescribedBy properties on Fedora objects? Right now, these are server-managed. If a user wishes to express the relationship between a given NonRDFSource and an object that describes it, using the iana:describes/iana:isDescribedBy predicates, they cannot do so. They would need to use terms from another vocabulary or ontology
- Should Fedora, in its core codebase, as a value-add service, add additional "Link rel=describedBy" headers on NonRDFSources, based on the existence of resources in the repository that claim to describe it?
- If yes, what is the mechanism by which the repository determines when a resource is describing a NonRDFSource?
- Is it the presence of specific "special" properties such as iana:describes or iana:isDescribedBy?
- If so, where must these specific properties be asserted (i.e. in the properties of the NonRDFSource, or by the describing object)?
- Is it the presence of specific "special" properties such as iana:describes or iana:isDescribedBy?
- If yes, what is the mechanism by which the repository determines when a resource is describing a NonRDFSource?
- Dealing with fcr:metadata:
- Requirements
- Option 1
- F4 shall continue to auto-create the <resource>/fcr:metadata NonRDFSource description.
- F4 clients may create other NonRDFSource descriptions, called client-descriptions.
- Client-descriptions shall indicate the NonRDFSource which they describe by including the following triple:
<client-description> some-fedora-ns:describesNonRDFSource <:B>
...where B is a NonRDFSource - F4 shall include a Link header in response to HTTP GET /client-description of the form:
Link: <:B>; rel="describes"
...where B is a NonRDFSource - F4 shall include Link header(s) in responses to HTTP GET /NonRDFSource of the form:
Link: <server-created-description>; rel="describedby"
Link: <client-description0>; rel="describedby"
Link: <client-description1>; rel="describedby"
Link: <client-descriptionN>; rel="describedby"
...where <server-created-description> is currently <resource>/fcr:metadata, but could change in the future. See: http://www.w3.org/TR/ldp/#ldpc-post-createbinlinkmetahdr
...where <client-descriptionX> is any NonRDFSource description that contains a triple as detailed above with predicate, some-fedora-ns:describesNonRDFSource, and object of this NonRDFSource. - Server-created-descriptions shall be non-container LDP Resources, http://www.w3.org/TR/ldp/#ldpr-gen-linktypehdr .
- Option 2
- F4 shall auto-create a NonRDFSource description as an LDP Basic Container (currently <resource>/fcr:metadata), called server-created-description
- Triples in the server-created-descriptions shall all have the same subject, the NonRDFSource being described
- F4 clients may create additional NonRDFSource descriptions by POSTing to the server-created-description container
- Option 1
4.2.1 Release manager?
Requirements- Single subject in RDF
- User-definable descriptions of binary resources (non-RDF resources)
- In addition to the default fcr:metadata?
- Instead of the default fcr:metadata?
- User-definable descriptions of binaries that can be Containers
- LDP link header "describedby" on Binary to description Remove description (if auto-created) when binary is removedRemove binary when description (if auto-created) is removed??
- Fedo Raadmin: this isn't required by LDP-- does Fedora want to require it? A. Soroka: If a bitstream has no retrievable properties, how to supply system-managed properties like date-modifed? What about fixity or audit info?
Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 - ...
Minutes
...
- Open Repositories committer meeting reflections
- fcr:metadata and NonRDFSource descriptions
- API extension framework to provide a Fedora 4 equivalent to disseminators or other kinds of functionality, independent of the core Fedora 4 codebase
- How do we align our REST API with standards, partitioning the API, adding test compatibility kits, etc.
- Improving codebase by taking advantage of Java 8, reducing dependency sprawl, OSGI-ifying Fedora
- Some dependency conflicts with the Servlet API version that complicate supporting Karaf and Tomcat 7
- High-level benefits of OSGI are being able to add and remove modules at runtime, and not need the webapp-plus project to pre-compose different options
fcr:metadata and NonRdfSource descriptions
- There are limitations to the NonRDFSource descriptions (fcr:metadata): can't use blank nodes or hash URIs, child nodes or child NonRDFSources
- We can add some of that functionality to fcr:metadata, e.g. blank nodes and hash URI support – this seems uncontroversial and we can probably just file a ticket
- The other use case is NonRDFSources that describe other NonRDFSources (e.g., FITS that describes a TIFF)
- This could be accomplished by creating child NonRDFSources, or making fcr:metadata a container, or allowing linking to a separate container
- Option 2 is to make fcr:metadata a container, which would allow changes
- General agreement that NonRDFSource descriptions should have a single subject and it should be the binary
- Some uneasiness about the subject, but having it be a single-subject description will make it easier to change if we look at how other LDP implementations handle this.
- A different approach would be to allow creating different kinds of deletion policies:
- Delete the link
- Delete the linked resource
- Return an error
- Supporting these different kinds of policies would be a Fedora-ism, but in support of LDP – maybe an extension.
Action: Esme will create two tickets:
- fcr:metadata should be a container
- fcr:metadata should have a single subject (the NonRDFSource URI) – this may exist
4.2.1 Release manager?
- Good to have periodic releases, and even better to get more people involved in the release process
- Nick volunteered to be the release manager for 4.2.1.