-
Notifications
You must be signed in to change notification settings - Fork 2
Standards Alignment Prototype
Priorities:
- Get data services working (project elements described below) 1a) Just get alignment data going 1b) All the features we discussed today...
- Get a trimmed down node running w/out slice -- ready for development. Install data services on it - show it works. (This is a question - I think this step make sense)
- Prove out test cases on this work
- Get docs in shape for examples and code lib
- Get one more example data service going: maybe ratings
- Get replicate working better (including this stuff but also pull-replicate)
- Get publish signing on a node working
Map/Extraction Functions: Standards alignment Provide these capabilities (maybe one per view or maybe integrated): Give me all standards aligned to URL/resource Give me all URLs associated with a standard Give me all alignment data Give me all aligned resources for a URL pattern / site
1a Story: What defines "alignment data"?
- Anything that starts with "http://purl.org/ASN/resources/*"
- XML with dct:conforms_to
- Criteria for relevant paradata (specific verbs for paradata)
- validate with Joe and Brian to identify rules of thumb
- define regex
- wiki article
1a Story (Jim): How do we organize (pattern) the data so it can be accessed in a consistent manner
- by date
- by sender
- by domain name (identity)
- by url
- by standard
- related to API format definition
1a Story (Jim): How to use the Java View Server to write the map functions?
- How to setup Maven
- Java
- not rich query interface
- wiki article
1b Story: How to use the JavaScript to write the map functions?
- Javascript
- not rich query interface
- wiki article
Calling / API format Use restful-like interface but modified to support parameters Call it "obtain_view" (or suggest alt) Parameters include: Which map/extract to run, primary param (URL of resource or whatever), secondary params (provided after "?") Security / access
- Each map/extract design doc needs to hold an arbitrary parameter that describes if the map/extract is permitted to be accessed from the "obtain_view" interface (obtain_view must honor this)
- Possibly also enable access from "obtain_view" by convention of naming the map/extract view function with a particular prefix like "view-[name]" (e.g., "view-by-standards-url") Example: Model: http://lr-node/obtain_view/[view-name]/[primary-parameter]?sender=[value] Live: http://lr-node/obtain_view/view-by-standards-url/http%3A%2F%2Fwww.youtube.com%3Fv%3Dxyzabc?sender=http%3A%2F%2Fpool.sks-keyservers.net%3A11371%2Fpks%2Flookup%3Fop%3Dget%26search%3D0xBFF13965146B1740
1a Story (Walt/Jim): What is the API definition?
- related to organize (pattern) data story
- leverage CouchDB tools, but abstract the API to use them (e.g., how to use CouchDB List function/view/regex, so we may need abstract a way to pass arbitrary parameters (e.g., domain name regex) through API to a CouchDB List?)
- unrestricted, but obivously no access to internal views
6 Story (Austin, LM security): Define how to restrict access to the API
- Define security ** Each map/extract design doc needs to hold an arbitrary parameter that describes if the map/extract is permitted to be accessed from the "obtain_view" interface (obtain_view must honor this) ** Possibly also enable access from "obtain_view" by convention of naming the map/extract view function with a particular prefix like "view-[name]" (e.g., "view-by-standards-url") ** role-based access (single role initially as discriminator)?
- wiki article documenting API
6 Story (Austin): How to restrict access to the API?
- Implement security ** Each map/extract design doc needs to hold an arbitrary parameter that describes if the map/extract is permitted to be accessed from the "obtain_view" interface (obtain_view must honor this) ** Possibly also enable access from "obtain_view" by convention of naming the map/extract view function with a particular prefix like "view-[name]" (e.g., "view-by-standards-url") ** role-based access
Result formats Use obtain result format Relax certain LR envelope elements for output by creating a new envelope doc_type: "result_data" "result_data" doc_type would have compatibility with "resource_data" but used for returning data which are composites of inputs Design goals include: Ability to chain result sets together Optional/bonus: Ability to submit result_data docs back into LR network
1a Story (Walt, Dan): What is the result format for the service?
- model obtain
- wiki article
1a Story (Walt, Dan): What is the result format for the envelope?
- model after resource_data, but with relaxed element definitions
- doc_type="result_data"
- wiki article
Filter Functions: Standards alignment and/or general purpose Examine whether performance requires some filters to be map/extractions. Filter by sender Filter by date
Addressed in above 1a story (organize data, API definition)
Tests Unit tests for components (may be language specific, using new or existing frameworks - should be callable from our overall test runner) Integration/functional tests (use our existing framework)
Part of the asynchronous development process is writing tests and doing code reviews
View server Templates for view Helper functions and other templatizing tools How-to examples Java view server Performance: make sure >= javascript view server Maybe provide javascript view servers templates as learning examples
4 Story: Provide example map functions in simulator
Design goal: Reduce server cost, improve performance, reduce resource allocation Reducing size of data and cost/size of server Data results window size needs to be small Going to EBS for disk storage
Design goal: Simplicity Every step can be done with curl
Second project: Submission envelopes signing by nodes
Signing submissions via node Wizard for creating public/private keys and uploading to key servers Associate public/private keys to basic_auth login users Signing code on submission inside node Could sign all stuff with a single node public/private key and associate basic_auth credentials as "signed on behalf of"