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 IR Minimum Viable Product #31

Open
bryjbrown opened this issue Aug 23, 2016 · 10 comments
Open

CLAW IR Minimum Viable Product #31

bryjbrown opened this issue Aug 23, 2016 · 10 comments

Comments

@bryjbrown
Copy link
Member

What features should CLAW have in order to be considered a usable IR? List your required features below.

@bryjbrown
Copy link
Member Author

  • IP and chronological embargoes for objects and datastreams
  • Support for PDF-based objects
  • Support for binary-style objects (object behaves independently of file format)
  • Support for compound objects

@manez
Copy link

manez commented Aug 23, 2016

I'd definitely like to hear opinions about the binary-style objects handling. We don't technically have that in the 7.x stack (although Binary Object SP is in Labs), which has always seem like a gap to me. A nice opportunity to have CLAW offer a concrete improvement, perhaps.

@BCDigIR
Copy link

BCDigIR commented Aug 24, 2016

  • Support for both self-deposit and batch ingest pathways
  • Support for basic SEO (ex. metatags, XML sitemap)
  • Method for gathering usage statistics/metrics on individual objects/datastreams

@dmoses
Copy link
Contributor

dmoses commented Aug 28, 2016

I'll have to look at the CLAW MVP, but I think the minimum would be:

  • support for descriptive metadata
  • support for an associated binary stream
    -- it could be a PDF or some other type?
    -- the system could use the mimetype of the binary to provide a default viewer?
  • a method to record metrics
  • batch import using standard identifiers would be helpful. ORCID has an interesting pattern for importing citations from CrossRef.
  • some sort of security policy that can be attached to the object or datastreams

@bradspry
Copy link

It is a repository, so I recommend focusing on ensuring repository objects are safe and sound.

  1. premis
  2. checksum
  3. checksum checker
  4. bag-it
  5. fits

@DonRichards
Copy link
Member

  • Accessibility Compliance Google Scholar Integration
  • Tracking (kinda like Google Analytics but on object level)

@BuddyinKC
Copy link

A default LICENSE datastream to store hidden pdf or xml license agreements with the work object with an integrated ingest mechanism to enable users to ingest a work object and a license object seamlessly would be very useful.

@bradspry
Copy link

bradspry commented Oct 12, 2016

@BuddyinKC, do you know the names of any machine-readable licenses or rights statements? I know of ONIX-PL, but ONIX-PL doesn't address rights. For example, are there any rights.xml schema which addresses IP Filtering rights, a.k.a. locking an object to a campus' IP range? Or a date-based license.xml or rights.xml like "we grant you streaming rights until MM-DD-YY"?

@BuddyinKC
Copy link

@bradspry, good question. A couple of things come to mind. There are ones for creative commons licenses. Also, A NISO working group has proposed best practices for access and license indicators (http://www.niso.org/apps/group_public/download.php/14223/rp-22-2015_ALI.pdf) that includes some XML implementation guidelines. There is some push to make this consistent across scholarly publishers and so there may be an opportunity to provide this consistency in IRs as well.

@alexkent0
Copy link

Someway to include default copyright statements and the ability to select more? This could at least give people a place to start. http://rightsstatements.org/en/ could be a place to look for statements that could be applicable for a lot of sites.

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

No branches or pull requests

8 participants