search

CenterForOpenScience / SHARE

SHARE is building a free, open, data set about research and scholarly activities across their life cycle.
http://share-research.readthedocs.io/en/latest/index.html
Apache License 2.0
100 stars 58 forks source link

[content provider] DMPTool #22

Closed efc closed 6 years ago

efc commented 10 years ago

I just added provider documentation for DMPTool to the project. Public data management plans from roughly 800 sites can be shared from DMPTool to give consumers of the SHARE Notification Service early notice of new research and grant awards.

Patricia Cruse plans on sending along a pointer to the DMPTool API, I'll update the documentation when I get that. For now it includes the answers to our metadata sharing questions which were cleared today (7/22/2014).

erinspace commented 10 years ago

Hi all! @efc any news on when this API might be available? I found a blog post that they've started working on it, but no updates since July. Just wondering if you knew of anything we could get started on!

AndrewSallans commented 10 years ago

Bringing the lead dev into the conversation.... @mxsstrong can you update on DMPTool API status here?

efc commented 10 years ago

FYI, the conversation I had about DMPTool's API was with Patricia Cruse last month. I've just sent an email to see if we can dig up the docs on this API.

erinspace commented 10 years ago

Thanks for the updates and reaching out!

efc commented 10 years ago

From Trisha... Here is the link to the API info and we are continuing to work on this piece: https://github.com/CDLUC3/dmptool/wiki/API

erinspace commented 10 years ago

Awesome, thanks!

erinspace commented 10 years ago

I've gotten a chance to start looking the API, and it seems like we'll need a bit more documentation to get the info we need from the DMP tool API. Right now, the documentation only outlines how to get information related to the numbers of plans and admins that each institution has in the system. I've managed to poke around and also query for all of those "plans" themselves, using the API route https://dmptool.org/api/v1/plans, but haven't yet figured out how to filter those by date, or get the metadata information available in other services that we'd need, such as contributors, descriptions, keywords, and ids.

I don't think we can use this API with what we have right now, unfortunately. The functionality might well exist, or can exist soon, but I think we need to wait for the tool to mature a bit to get the most out of it.

marisastrong commented 10 years ago

CDL is on board for a code fest with the COS/OSF folks. We need to add some robustness to our existing API (ex: add authentication tokens for sensitive data, test infrastructure, etc) which we'll do before we meet up. Then we are hoping to tackle the first use case to support a living DMP with OSFhttps://github.com/CDLUC3/dmptool/issues/49.

We are looking at early to mid October for travel. We are mostly Rails developers – should we brush up on Python before we come?

Marisa

From: Erin Braswell notifications@github.com<mailto:notifications@github.com> Reply-To: CenterForOpenScience/SHARE reply@reply.github.com<mailto:reply@reply.github.com> Date: Tuesday, August 26, 2014 4:47 PM To: CenterForOpenScience/SHARE SHARE@noreply.github.com<mailto:SHARE@noreply.github.com> Cc: Registered User marisa.strong@ucop.edu<mailto:marisa.strong@ucop.edu> Subject: Re: [SHARE] [content provider] DMPTool (#22)

Yo @fabianvfhttps://github.com/fabianvf , here are some links that will help us do this when we get to it!

http://www.dalkescientific.com/Python/PyRSS2Gen.html https://pythonhosted.org/DeeFuzzer/deefuzzer.deefuzzer.tools.PyRSS2Gen.RSSItem-class.html

but perhaps the most helpful: http://stackoverflow.com/questions/1766823/how-can-i-generate-rss-with-arbitrary-tags-and-enclosures

— Reply to this email directly or view it on GitHubhttps://github.com/CenterForOpenScience/SHARE/issues/22#issuecomment-53509369.

efc commented 10 years ago

Here is a note from Stephen Abrams at CDL as well:

The current state of the DMPTool API is admittedly fairly minimal. What is there is documented at https://github.com/CDLUC3/dmptool/wiki/API. The needs most often expressed during the development phase was for summary usage metrics, so that is what we have provided. However, we are eager to collect additional use cases that will inform our ongoing enhancement efforts. You can see some potential use cases documented in the GitHub issue tracker, https://github.com/CDLUC3/dmptool/issues, tagged with the “API use cases” label. We would encourage you to add to this list based on your requirements.

By the way, I’ll be coming to DC for the October SHARE meeting; looking forward to seeing you then.

erinspace commented 10 years ago

@mxsstrong, thanks so much for the info, and we are looking forward to working together! I just wanted to add, I took a look at the API code and found much more information that I myself had missed, sorry about that. There might well be more information that's out there that I'm missing still, and I'll keep looking. I also wanted to say thank you for the clear and helpful documentation that you've provided so far!

As per Stephen's suggestions via Eric, we will definitely add to the list as suggested, thank you for pointing us to that resource.

AndrewSallans commented 10 years ago

Great to see everybody talking in here. Just to be clear, we have two things being discussed in this conversation:

(1) Details for how to consume content from the DMPTool API for SHARE. This is what Erin is focused on now.

(2) Mention of other plans for API integration between the DMPTool and OSF. That's a broader conversation with a different timeline and path, and not related to SHARE.

Both are important, but different development priorities. Just clarifying to avoid confusion for anyone not aware of the other.

erinspace commented 9 years ago

Hello everyone!

We thought it might be helpful if we outlined the metadata that we're trying to collect from other SHARE sources on this particular discussion, though before I added this SHARE use case as an addendum to the previous COS use case on the DMP Tool API issues page. Here is the same thought again in case that's helpful for separating out the two ideas!

We've come up with a preliminary schema for the SHARE notification output, which you can see in more detail on the wiki. We don't need every piece of data from each service, rather whatever we can gather.

Right now, it looks like the plans route in your API provides...

It'd be awesome if your API could also provide

We usually try to collect a few more pieces of information only if they're available, which include:

I was speaking with @AndrewSallans about the different id codes provided in the current output (current_plan_state_id, requirements_template_id, and the solicitation_identifier), and we thought that In addition to giving the id number, it'd be awesome if we could also grab the text the ID number refers to so that others know what they stand for, and it can be linked to other resources and aggregate data within SHARE.

In addition, it'd be great if there was also a way to filter the API request by

...so that we could make a smaller request to check to see if anything has been updated, and then only consume the information that is set to public.

Let me know if there's any more information you need or anything we can do to help out. Thanks so much again!

marisastrong commented 9 years ago

Hi Erin,

Thanks for added input as to what information you'd like to extract from DMPTool.

I have a couple of questions.

For contributors, I assume you mean co-owners to a plan?

What are you referring to as a resource? We use the term resource to support a DMP Template and is not associated with a particular DMP. For example, if you are working on an NSF template and answering questions, a resource would provide additional information specific to the NSF Template.

We don't have URLs or DOIs.

Marisa

From: Erin Braswell notifications@github.com<mailto:notifications@github.com> Reply-To: CenterForOpenScience/SHARE reply@reply.github.com<mailto:reply@reply.github.com> Date: Thursday, September 18, 2014 1:51 PM To: CenterForOpenScience/SHARE SHARE@noreply.github.com<mailto:SHARE@noreply.github.com> Cc: Marisa Strong marisa.strong@ucop.edu<mailto:marisa.strong@ucop.edu> Subject: Re: [SHARE] [content provider] DMPTool (#22)

Hello everyone!

We thought it might be helpful if we outlined the metadata that we're trying to collect from other SHARE sources on this particular discussion, though before I added this SHARE use case as an addendum to the previous COS use case on the DMP Tool API issues pagehttps://github.com/CDLUC3/dmptool/issues/49. Here is the same thought again in case that's helpful for separating out the two ideas!

We've come up with a preliminary schema for the SHARE notification output, which you can see in more detail on the wikihttps://github.com/CenterForOpenScience/SHARE/wiki/Current-SHARE-schema. We don't need every piece of data from each service, rather whatever we can gather.

Right now, it looks like the plans route in your APIhttps://dmptool.org/api/v1/plans provides...

It'd be awesome if your API could also provide

We usually try to collect a few more pieces of information only if they're available, which include:

I was speaking with @AndrewSallanshttps://github.com/AndrewSallans about the different id codes provided in the current output (current_plan_state_id, requirements_template_id, and the solicitation_identifier), and we thought that In addition to giving the id number, it'd be awesome if we could also grab the text the ID number refers to so that others know what they stand for, and it can be linked to other resources and aggregate data within SHARE.

In addition, it'd be great if there was also a way to filter the API request by

...so that we could make a smaller request to check to see if anything has been updated, and then only consume the information that is set to public.

Let me know if there's any more information you need or anything we can do to help out. Thanks so much again!

— Reply to this email directly or view it on GitHubhttps://github.com/CenterForOpenScience/SHARE/issues/22#issuecomment-56101233.

AndrewSallans commented 9 years ago

Hi Marisa,

Jumping-in here to see if what I know from both sides might help...

-By contributors, we are looking for what DMPTool calls "Owners" and "Co-Owners", and for each of those records, we'd ideally like the associated full name (need), email (need), and ORCID (if they've provided it). We'll be looking to grab these only as they relate to the DMP as the main object, and do not have a need for just grabbing a list of Owners/Co-Owners.

-By resource, we are not looking for what DMPTool defines as a resource. Instead, we just mean an extension of the persistent identifier of the DMP. The current API provides this as {"id":value). It would be really helpful to also have the constructed url, if that's something you can easily provide (I think having it would just simplify the process on our end). An example is: https://dmptool.org/plans/8329.pdf Right now, that would come across as {"id":8329} and then we'd need to create the url around it for the notification service. Would it be feasible to provide such a url?

Hope that helps clarify.

Best, Andrew

laurenbarker commented 6 years ago

Going to close this issue since it hasn't been updated since 2014.