princeton-cdh / bluemountainsprings Goto Github PK

no data?

how they manage it; licensing; etc.

See attached screenshot;
authentication.zip

To the maximum extent possible, the API should perform error checking on requests, and should always return a meaningful status, either with the resulting data or an indication that the request was invalid or that the data was not available.

It would be convenient to add a request parameter that would allow users to specify the format they want. This would make it easy for users to explore the API via browser without having to use curl or other scripted tools, and would also make it possible to link directly to a particular result, which could be helpful in demonstrating using the API output with other tools.

Brian Kernighan will direct a Code Review of the Blue Mountain Springs Code Base.

Show how you can start at the top levels (/magazines, /contributors) and extract data all the way down.

2-3 pages,

Describe goals reached, and both scholarly and technological outcomes of the project.

Briefly describe the public-facing outcome of your CDH grant year. If this includes a website, provide a link to the website.

Explain major changes and discrepancies with planned work.

Review and update (if necessary) your project blurb on the CDH website. Provide a link to your public-facing research outcome and data repository.

Get the slide decks Natasha & I prepared for the conference and make them available somehow.

So it's finally happened: we know who somebody is but neither viaf nor the loc have an id for him. So we need to start creating our own name authority files. Ah, the joy...

Seems like it would be a good idea to have something here. JSON with information about available endpoints? Redirect to springs/api ?

Shaune points out

{
"title": "Action: cahiers individualistes de philosophie et d'art"
}

should be:

{
"label": "title",
"value": "Action: cahiers individualistes de philosophie et d'art"
}

The Github repository should include at least links to all BMS documents so that there is a single reference point from which every public project document can be accessed. It is left to your discretion whether existing documents are imported or left as is on other servers.

The default return format should be consistent when no accept header is specified. Seems to default to csv in some cases, json in others, and tei in others. If there is not a common format available for all API requests, then include that in the documentation and explain the order of precedence of the default return format based on what formats are available for a given API request.

The last time I checked, this returned a 404 Not Supported.

HEAD request support would be helpful for people investigating the API to see what formats are accepted, etc.

Review and update (if necessary) your project blurb on the CDH website. Provide a link to your public-facing research outcome and data repository.

returning full representation for each issue (timing out on dev server); should only be returning uri of each issue.

still using mods

invalid bmtnid; etc.

Talk with John Kazmierski; can we test this without having to spin up another dev VM?

The API specification appears to be complete, but you should ensure that each object in the abstract data model maps to a path in the RESTful API, as appropriate.

Provide an open-access copy of your data, with a brief readme file with a brief description of the data, structure/organization, and data types.

• complete metadata cleanup
• generate all derivatives
• write README file

The installing.html file referenced in the README provides useful installation instructions, but is not easily readable on GitHub. I recommend including it in the GitHub pages site and then linking directly to the current version from the readme. (Alternatively, you could convert the installation instructions to markdown for easy display on GitHub directly.)

Might be nice to link to exist documentation on the package manager, for anyone who needs more info/help on installing package dependencies.

Also consider adding a link to the github pages site more generally.

• Complete APIs

Generate readme file containing the following:
1-2 paragraph description of project
link to cdh website and any other public-facing project website
description of repository organization
installation and dependency information or instructions
any known issues or customization points

Proposed budget
Accepted budget
Actual spent (contact Sarah Meadows to provide)

Contact Dot Porter to find out how they are handling:

traffic
licensing

The API documentation should be expanded to include more examples of searches and queries that users might want to perform; in effect, these are additions to the tutorial material. BMS has only a small user population at this point, so it is difficult to speculate about what kinds of searches might be representative. Your additions should cover a reasonable spectrum of possibilities, but need not be exhaustive.

The examples should include a complete instance of how to connect the results of a BMS query to Voyant, and an instance showing how to connect to Palladio, as representatives of widely used DH systems.

The examples should also include at least one instance of using the API to query BMS from a standard programming language like Ruby or Python, parsing the resulting JSON or XML and performing some analysis or reformatting on it.

All examples must have been tested and must work as shown.

Include documentation of the API, plus example uses (in conformance with the CDH contract)

On my initial tests, API requests returned 500 errors when no data was loaded; it should have error handling throughout.

• magazines/id should return a 404 Not Found when the referenced id is not found
• issues/id should return a 404 Not Found when the referenced id is not found

Any other API endpoints that reference ids should return 404s if the id is not found in the loaded data.

Any requested URL that doesn't match a valid API endpoint should return a 404.

Expand testsprings.rb to do a more exhaustive walk of the resource.