Page History

...

1. Open Repositories committer meeting reflections

2. fcr:metadata and NonRdfSource descriptions

   1. Requirements
      1. Single subject in RDF
      2. User-definable descriptions of binary resources (non-RDF resources)
         
         1. In addition to the default fcr:metadata?
         2. Instead of the default fcr:metadata?
      3. User-definable descriptions of binaries that can be Containers
      4. LDP link header "describedby" on Binary to description
      5. Remove description (if auto-created) when binary is removed
         1. Remove binary when description (if auto-created) is removed??
            
            1. Fedo Raadmin: this isn't required by LDP-- does Fedora want to require it?
            2. A. Soroka: If a bitstream has no retrievable properties, how to supply system-managed properties like date-modifed? What about fixity or audit info?
   2. Questions on the table:
      1. Dealing with fcr:metadata:
         1. Should fcr:metadata, as an LDP-RS with a URI distinct from the
            LDP-NR, exist at all?
            1. If yes, should the contents of fcr:metadata be refactored
               such that all triples have only one subject?
               1. If yes, what should that subject be?
            2. 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?
            3. 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?
      2. Dealing with Fedora resources, created by a user, to describe
         NonRDFSources:
         1. 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
         2. 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?
            1. If yes, what is the mechanism by which the repository
               determines when a resource is describing a NonRDFSource? 
               
               1. Is it the presence of specific "special" properties such as iana:describes or
                  iana:isDescribedBy? 
                  
                  1. If so, where must these specific properties be
                     asserted (i.e. in the properties of the NonRDFSource, or by the
                     describing object)?
                     

3. 4.2.1 Release manager?

4. 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

5. 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

6. ...

...