...
- Open Repositories committer meeting reflections
fcr:metadata and NonRdfSource descriptions
- Requirements
- 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 other NonRDFSource descriptions, called client-descriptionsF4 clients may create additional additional NonRDFSource descriptions by POSTing to the server-created-description container
- 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)?
- 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
4.2.1 Release manager?
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 - ...
...