Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLAW Harvest Use Cases, Features, etc. #38

Open
uconnjeustis opened this issue Dec 19, 2016 · 13 comments
Open

CLAW Harvest Use Cases, Features, etc. #38

uconnjeustis opened this issue Dec 19, 2016 · 13 comments

Comments

@uconnjeustis
Copy link
Contributor

It would be great to have the following features with harvests going forward:

  • Deletion support.
  • Ability to have oai sets based on namespaces. This would greatly facilitate sharing data.
@alehman-loc
Copy link
Contributor

alehman-loc commented Dec 19, 2016

@uconnjeustis Are you talking about the Islandora OAI Module? Or do you have another way that this works?

@uconnjeustis
Copy link
Contributor Author

@Amandarl Yea... sorry. This is in reference to the Islandora OAI Module. I thought it would be great to add this as it is related to metadata. I know that CLAW has included deletion support already!

@ruebot
Copy link
Contributor

ruebot commented Dec 20, 2016

I know that CLAW has included deletion support already!

Where is that mentioned?

@ruebot
Copy link
Contributor

ruebot commented Dec 20, 2016

Ability to have oai sets based on namespaces. This would greatly facilitate sharing data.

Namespaces are not a thing in Fedora 4. I'd definitely check out this use case: Islandora/documentation#396

@uconnjeustis
Copy link
Contributor Author

uconnjeustis commented Dec 20, 2016

@ruebot I thought I remember hearing something about deletion support at the Fedora 4 camp in NYC. It was in the discussion about the tombstones. I don't know if there's any documentation or formal mention of it.

Thanks for bringing that up @ruebot. The use case that I'm thinking of is slightly different in that we work with different institutions where we need to distinguish their content in some way. We use namespaces that are assigned to each institution. Some namespaces designate content that shouldn't be harvested as well. In future, we would like to be able to provide these institutions with the ability to harvest their content (oai set). In the fedora3 view this would be a namespace set.

@ruebot Would it make sense to develop this a little using the use case template and add it to Issue 396?

@ruebot
Copy link
Contributor

ruebot commented Dec 20, 2016

Fedora 4 does tombstoning. This would allow for a future, as yet designed, Islandora CLAW OAI-PMH module allow for OAI-PMH deletion support. Deletion support in CLAW is outlined in the MVP -- see: Delete a Resource -- and will use the default Fedora 4 behaviour of tombstoning.

I think the best course of action would be to arrange some community conversations about what the community would like to see w/r/t to OAI-PMH support in a Islandora. Then that would allow us to pull together fuller use cases, identify stakeholders, and resources to implement this.

Namespaces are a separate, but I can see how it is related, issue. If you have thoughts or opinions there, I would definitely weigh in on Islandora/documentation#396, and would also suggest the same thing as about with a community led discussion, and identify stakeholders and resources to make it happen.

@mrmiguez
Copy link

mrmiguez commented Jan 5, 2017

Something else that would be useful:

Serializing JSON-LD to harvesters as well as XML.

@uconnjeustis
Copy link
Contributor Author

@mrmiguez Are you thinking of aggregators like DPLA?

@mrmiguez
Copy link

mrmiguez commented Jan 6, 2017 via email

@uconnjeustis
Copy link
Contributor Author

This might be dumb question. But can DPLA take json-LD?

Continuing with OAI harvests, I would also like the ability to select what constitutes a set. I could see some uses to be able to select only top level collections or all collections.

@mrmiguez
Copy link

mrmiguez commented Jan 9, 2017

They can! Though I don't think anyone is delivering it yet. During the service hub application process, we were encouraged to try giving them JSON-LD. One of the (dis)advantages of being late the the service hub game?

@uconnjeustis
Copy link
Contributor Author

This is brand new and definitely something to investigate. I'm thinking of gathering some of these ideas in a series of use cases. We have the MODS to RDF discussion today (1/9/2017) at the MIG. This could be a great discussion for February.

@uconnjeustis
Copy link
Contributor Author

uconnjeustis commented Jan 15, 2017

I wanted to sum up some of the features for harvesting in this user story. I'd like to bring this story to the attention of the claw group. If you'd like more features, add to the remarks or enhance the story.

Title (Goal) OAI-PMH Harvest
Primary Actor Repository Administrator
Scope access, configuration, configuration
Level TBD
Story As a repository administrator, I would like to have a configurable OAI-PHM harvest that would expose metadata in multiple formats to either users or data harvesters.

Remarks on configuration

  • Name of repository
  • Path to the repository
  • Repository unique identifier
  • Administrator email
  • Maximum response size
  • Expiration time
  • Exclude types of content
  • Ability to have no OAI sets or have sets by types of content and/or collections
  • Ability to append thumnail identifier to any request (whether DC, MODS, etc.)
  • Support deletion
  • Ability to configure harvest for Dublin Core, MODS, JSON-LD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants