Post-4.2.0 Fedora Features

[Andrew Woods]

Hello All,

As Fedora4 continues to see increased adoption and usage, the following unimplemented capabilities have been identified as being of particularly high value to the user community. Each of these represents an opportunity for Fedora stakeholders to collectively define specific feature requirements as well as join in a coordinated development effort.

If there is enough interest and stakeholders for any or all of the following features, we can begin planning appropriate feature sprints.

As a starting point, please respond to this thread indicating your interest in one or more of the following features, and an ability to commit time towards specifying/verifying, and/or implementing any of them.

-----

Feature 1: Asynchronous Storage

-----

This feature has two aspects. On the backend it would allow Fedora to communicate asynchronously with high-latency storage systems, including hierarchical storage management systems and cloud storage. On the frontend the Fedora REST-API would be updated to expose an asynchronous client interaction.

-----

Feature 2: Web Access Control

-----

Web Access Control [1] is another emerging W3C specification that provides a linked data mechanism for representing and enforcing access control. This feature provides an avenue for standardization and inter-operability of access control. Both the Hydra and Islandora communities are interested in implementing this standard, though at present there is no mechanism to enforce it at the Fedora level. We would need to develop a Web Access Control module to plug into the Fedora 4 authorization framework, which is what this work would entail.

[1] https://www.w3.org/wiki/WebAccessControl

-----

Feature 3: Human-Readable Filesystem

-----

In this context, a human-readable filesystem in Fedora 4 means having bitstreams and metadata co-located on a filesystem in a predictable location. The metadata would be serialized in a text format that could be parsed and inspected by standard utilities, such as those commonly found on Unix-based systems. Preliminary discussion [2] have already begun on this issue.

[2] https://wiki.duraspace.org/display/FF/Design+-+Transparent+Persistence

Regards,

Andrew

[Stefano Cossu]

Hi Andrew,
I am definitely interested in #2 and can provide testing and sample policies.

Thanks,

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

--
You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leader...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Woods]

Hello Tom,

When you say +1 (or +2) are you saying that you are available to participate in the process of defining requirements and user verification? or dedicating development staff to an implementation?

Thanks,

Andrew

On Thu, May 21, 2015 at 8:22 AM, Thomas Murphy <tomu...@umich.edu> wrote:

+2 on 1

+1 on 2 

no preference on 3

Tom Murphy

Director - Computer & Network Services

University of Michigan - ICPSR

330 Packard St

Ann Arbor, MI.  48104

tomu...@umich.edu

[Andrew Woods]

Thanks, Tom.

Having your team's deeper involvement would be fantastic. Please keep the community posted.

Andrew

On Thu, May 21, 2015 at 9:21 AM, Thomas Murphy <tomu...@umich.edu> wrote:

I think at a minimum we should be able to help with requirements. I am in budget discussions this week and am pushing for staff that I can also use more consistently on Fedora Community efforts.

Tom Murphy

Director - Computer & Network Services

University of Michigan - ICPSR

330 Packard St

Ann Arbor, MI.  48104

tomu...@umich.edu

[Joshua Westgard]

Features 1 (Asynchronous Storage) & 2 (Web Access Control) are both of interest to us.  If I had to rank them I would give priority to #2 because that could have more immediate benefits for our current implementation (or at least I think so; our developers have yet to weigh in on the question of which access control method will best fit our needs).

I can commit myself to requirements development and stakeholder participation in 1 and/or 2.  Developer time is not up to me, and given our recent commitment of developer time I'm not sure how realistic that would be, but I can try to make a case for it.

On #3 I don't have a strong opinion or a specific use case to offer.

Josh

[Julie Allinson]

Hello,

We have an interest in Feature 2 being long time users of xacml in F3. We could contribute something on requirements and testing.

Cheers,

Julie

[Jared Whiklo]

Hi Andrew,

I think we have an interest in #2 (WebACL) as well. I can probably find some time to dedicate to it, I will have to confirm this though.

cheers,

jared

[Nick Ruest]

+1 to WebACL + Islandora integration.

-nruest

> <https://wiki.duraspace.org/display/FF/Design+-+Transparent+Persistence>
>
> Regards,
> Andrew
>
> --
> You received this message because you are subscribed to the Google

> Groups "Fedora Tech" group.

> To unsubscribe from this group and stop receiving emails from it, send

> an email to fedora-tech...@googlegroups.com
> <mailto:fedora-tech...@googlegroups.com>.
> To post to this group, send email to fedor...@googlegroups.com
> <mailto:fedor...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/fedora-tech.

[Esmé Cowles]

Andrew-

UCSD is interested in #3 and should have the development resources to implement it later this summer.

-Esme

> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.

[Dunn, Jon William Butcher]

Hi Andrew,

 

This may be too late given your message earlier this afternoon. I’ve been heads-down on OR15 planning and am only now catching up on my Fedora email, but Indiana University is very much interested in Feature 1: Asynchronous Storage. As this is a requirement for successfully meeting the objectives of our NEH grant for the HydraDAM2 project, we are interested in contributing time to specification, verification, and/or implementation. I’m happy to talk more at OR about potential timeline.

 

Jon

--
You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leader...@googlegroups.com.

[Andrew Woods]

Hello Jon,

To be honest, I was expecting you or someone from Indiana or WGBH to jump into the conversation earlier. It would be fantastic to begin moving forward with the Asynchronous Storage feature. In addition to relating to the NEH grant in which you are involved, the feature potentially unlocks a variety of interesting, massively scalable, offsite, online storage opportunities.

As you know, Fedora is not built by elves in the night. If there is additional, unvoiced community interest in developing Asynchronous Storage, let's make it happen! What I heard in this thread is that U of Michigan and U of Maryland have interest, but maybe no developers. I know your own development staff is thin at the moment. As much as I would like to see this happen, implementing this feature will require engagement from the broader community.

Jon, could you re-state your timeline? 

Everyone else, if you want to see Asynchronous Storage happen sooner than later, this is the chance. Please speak up.

Andrew

[Friscia, Michael]

+1 on async storage. By OR I will be able to talk how much programming support we can give.

_______________________________________
Michael Friscia
Manager, Digital Library & Programming Services
Yale University Library
(203) 432-1856
________________________________________
From: fedor...@googlegroups.com [fedor...@googlegroups.com] on behalf of Andrew Woods [awo...@duraspace.org]
Sent: Thursday, May 28, 2015 6:04 PM
To: Dunn, Jon William Butcher
Cc: fedora-community; fedor...@googlegroups.com; fedora-...@googlegroups.com
Subject: [fedora-tech] Re: [fedora-leaders] Post-4.2.0 Fedora Features

Hello Jon,
To be honest, I was expecting you or someone from Indiana or WGBH to jump into the conversation earlier. It would be fantastic to begin moving forward with the Asynchronous Storage feature. In addition to relating to the NEH grant in which you are involved, the feature potentially unlocks a variety of interesting, massively scalable, offsite, online storage opportunities.

As you know, Fedora is not built by elves in the night. If there is additional, unvoiced community interest in developing Asynchronous Storage, let's make it happen! What I heard in this thread is that U of Michigan and U of Maryland have interest, but maybe no developers. I know your own development staff is thin at the moment. As much as I would like to see this happen, implementing this feature will require engagement from the broader community.

Jon, could you re-state your timeline?
Everyone else, if you want to see Asynchronous Storage happen sooner than later, this is the chance. Please speak up.

Andrew

On Thu, May 28, 2015 at 4:47 PM, Dunn, Jon William Butcher <j...@iu.edu<mailto:j...@iu.edu>> wrote:
Hi Andrew,

This may be too late given your message earlier this afternoon. I’ve been heads-down on OR15 planning and am only now catching up on my Fedora email, but Indiana University is very much interested in Feature 1: Asynchronous Storage. As this is a requirement for successfully meeting the objectives of our NEH grant for the HydraDAM2 project, we are interested in contributing time to specification, verification, and/or implementation. I’m happy to talk more at OR about potential timeline.

Jon

From: fedora-...@googlegroups.com<mailto:fedora-...@googlegroups.com> [mailto:fedora-...@googlegroups.com<mailto:fedora-...@googlegroups.com>] On Behalf Of Andrew Woods
Sent: Wednesday, May 20, 2015 11:14 AM
To: fedora-community
Cc: fedor...@googlegroups.com<mailto:fedor...@googlegroups.com>; fedora-...@googlegroups.com<mailto:fedora-...@googlegroups.com>
Subject: [fedora-leaders] Post-4.2.0 Fedora Features

Hello All,
As Fedora4 continues to see increased adoption and usage, the following unimplemented capabilities have been identified as being of particularly high value to the user community. Each of these represents an opportunity for Fedora stakeholders to collectively define specific feature requirements as well as join in a coordinated development effort.

If there is enough interest and stakeholders for any or all of the following features, we can begin planning appropriate feature sprints.

As a starting point, please respond to this thread indicating your interest in one or more of the following features, and an ability to commit time towards specifying/verifying, and/or implementing any of them.

-----
Feature 1: Asynchronous Storage
-----
This feature has two aspects. On the backend it would allow Fedora to communicate asynchronously with high-latency storage systems, including hierarchical storage management systems and cloud storage. On the frontend the Fedora REST-API would be updated to expose an asynchronous client interaction.

-----
Feature 2: Web Access Control
-----
Web Access Control [1] is another emerging W3C specification that provides a linked data mechanism for representing and enforcing access control. This feature provides an avenue for standardization and inter-operability of access control. Both the Hydra and Islandora communities are interested in implementing this standard, though at present there is no mechanism to enforce it at the Fedora level. We would need to develop a Web Access Control module to plug into the Fedora 4 authorization framework, which is what this work would entail.

[1] https://www.w3.org/wiki/WebAccessControl<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_wiki_WebAccessControl&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=H69kYKzCdFGZ9nHKvxobUiOw20bdVi7TfYE-KrZlT_4&m=eAj_h0iE3Pit_Qm6bYoaKbiCD_o783AwvrW02U_VGQk&s=4VKRcLfWiDrib8xLoO_5ss2ALaRdNUsRIKb4ermi8x4&e=>

-----
Feature 3: Human-Readable Filesystem
-----
In this context, a human-readable filesystem in Fedora 4 means having bitstreams and metadata co-located on a filesystem in a predictable location. The metadata would be serialized in a text format that could be parsed and inspected by standard utilities, such as those commonly found on Unix-based systems. Preliminary discussion [2] have already begun on this issue.

[2] https://wiki.duraspace.org/display/FF/Design+-+Transparent+Persistence<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.duraspace.org_display_FF_Design-2B-2D-2BTransparent-2BPersistence&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=H69kYKzCdFGZ9nHKvxobUiOw20bdVi7TfYE-KrZlT_4&m=eAj_h0iE3Pit_Qm6bYoaKbiCD_o783AwvrW02U_VGQk&s=eB27orpZ0My6lGvpPnLrW4cMZCpgw-0tempuLlNurww&e=>

Regards,
Andrew

--
You received this message because you are subscribed to the Google Groups "Fedora Leaders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-leader...@googlegroups.com<mailto:fedora-leader...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=H69kYKzCdFGZ9nHKvxobUiOw20bdVi7TfYE-KrZlT_4&m=eAj_h0iE3Pit_Qm6bYoaKbiCD_o783AwvrW02U_VGQk&s=0_rIrFndL5_yIKkyJG56RJaCju9GtmP4SX833qncixY&e=>.


--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com<mailto:fedora-tech...@googlegroups.com>.
To post to this group, send email to fedor...@googlegroups.com<mailto:fedor...@googlegroups.com>.
Visit this group at http://groups.google.com/group/fedora-tech<https://urldefense.proofpoint.com/v2/url?u=http-3A__groups.google.com_group_fedora-2Dtech&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=H69kYKzCdFGZ9nHKvxobUiOw20bdVi7TfYE-KrZlT_4&m=eAj_h0iE3Pit_Qm6bYoaKbiCD_o783AwvrW02U_VGQk&s=au8dWsKx2PJUwgm3BTjuHaf0YX8INpgeOP57J-kM7IU&e=>.
For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=H69kYKzCdFGZ9nHKvxobUiOw20bdVi7TfYE-KrZlT_4&m=eAj_h0iE3Pit_Qm6bYoaKbiCD_o783AwvrW02U_VGQk&s=0_rIrFndL5_yIKkyJG56RJaCju9GtmP4SX833qncixY&e=>.

[Aaron Coburn]

I would add that, at Amherst, we are very interested in what you are calling asynchronous storage, particularly the ability to connect fedora (or segments thereof) to different cloud-based storage back-ends (e.g. S3 and Glacier). We may also have some developer resources to contribute to this effort.

Regards,
Aaron

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.

[Dunn, Jon William Butcher]

Hi Andrew,

The timeline of the IU/WGBH HydraDAM2 grant runs through December 2016. I think we’d ideally like to see Asynchronous Storage support by sometime in the first half of 2016. You’re right that we have been down several positions on our repository development team at IU, but we are starting to fill them and I’ll be talking more with Will this week about what level of effort we might be able to contribute to this.

Jon

[Ben Wallberg]

As Josh stated UMD is interested in both, but WebACL is a higher priority for us.  We would be willing to contribute two developers to a sprint as early as the week of June 29.

--
You received this message because you are subscribed to the Google Groups "Fedora Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-communi...@googlegroups.com.

[David Wilcox]

Thanks for the input, everyone. It looks like there is enough interest and capability to move forward with both asynchronous storage and Web Access Control, so we will plan to schedule initial stakeholder calls for later this month. Please keep an eye out for the Doodle poll that we will send around immediately following Open Repositories (likely June 15 or 16).

Regards,

David

-- 

David Wilcox

Fedora Product Manager
DuraSpace

dwi...@duraspace.org

Skype Name: david.wilcox82