Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
• International toll free:  http://www.readytalk.com/intl 
  
  • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
  • Once on the call, enter participant code 2257295
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Attendees 

• 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)
• Doron Shalvi

Agenda

1. Open Repositories committer meeting reflections

2. fcr:metadata and NonRdfSource descriptions

   1. Note of JCR Node structure

      NonRdfSourceDescription[JCR_NODE]
        |
        - FedoraBinary[JCR_NODE]
            |
            - datastream[JCR_PROPERTY]

   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. Requirements
      1. Option 1
         1. F4 shall continue to auto-create the <resource>/fcr:metadata NonRDFSource description.
         2. F4 clients may create other NonRDFSource descriptions, called client-descriptions.
         3. 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
         4. 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
         5. 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.
         6. Server-created-descriptions shall be non-container LDP Resources, http://www.w3.org/TR/ldp/#ldpr-gen-linktypehdr .
      2. Option 2
         
         1. F4 shall auto-create a NonRDFSource description as an LDP Basic Container (currently <resource>/fcr:metadata), called server-created-description
         2. Triples in the server-created-descriptions shall all have the same subject, the NonRDFSource being described
         3. F4 clients may create additional NonRDFSource descriptions by POSTing to the server-created-description container

3. 4.2.1 Release manager?

4. Tickets resolved this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

5. Tickets created this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

6. ...

Minutes