## Objectives
- Develop schema/models and map those onto objects/tables/rows/nodes/edges/RDF/RDF* in order to store instances
- Generate HTML + JS forms with clientside validation in order to CRUD instances and assure data quality (JSONschema?)
- Generate HTMLÂ + JS forms with serverside validation in order to CRUD instances and assure data quality (JSONschema?)
- Generate HTTP API for use with:
 - JS client app (browser, desktop, mobile)
 - Mobile app (mobile)
 - Clients that authenticate before making requests
- Pass through SPARQL queries made to the app to the backend SPARQL endpoint in order to validate/modify the query (e.g. the LIMIT clause)
- Expose all data through SPARQL endpoint
 - Prevent resource exhaustion ("DoS") due to reasonable use by more than one user
 - Support HTTP Content-Range requests and/or Paging/Pagination
 - Support [pass through?] authentication and possibly also authorization
 - Determine whether ther ultimate SPARQL server supports rate limiting and/or anything like an X-Forwarded-For header
*****
- TIL that pydal is the web2py SQL ORM and forms generation and validation library:
- Django ModelForms (and class-based views) are unfortunately somewhat tightly coupled to the Django ORM:
 "Unfortunate" because there may not be a good way to make a graph query interface quack exactly like a SQL ORM interface; so more abstraction *would be* necessary to maximally reuse the forms validation, CRUD scaffolding, and REST API features -- that we use batteries-included frameworks for -- with anything other than a SQL database. So, instead of trying to do SPARQL on top of SQL -- which is trivial with e.g. Virtuoso -- SQL applications can also just publish cached, URI-named JSON-LD documents and/or provide an e.g. W3C LDP HTTP API that other apps can easily copy data from into an on-disk or in-memory e.g. triplestore database as necessary.
- DRF (Django REST Framework) does lots of APIs very well.
 - I've mentioned why I think it's worth it to do LDP/SPARQL on DRF for all on Twitter before in the past;
  because the Django community is huge so high impact andÂ
  Linked Data in Django could be as easy as models.py / admin.py / api.py.
 - IIRC, DRF Validators and (De-)Serializers are not coupled to the Django ORM:
 - It's probably pretty easy to frame DRF API responses as JSON-LD; with an optional explicit @context that maps the framed JSON document structure to RDF; though then what are the named graph URIs for each [paged, possibly windowed] HTTP API endpoint responses?
- Generate HTML+JS forms with validation from one or more {RDFS, SHACL, JSONschema, OWL, Fresnel} schema
  > Perhaps there's some combination of e.g.
https://github.com/google/schema-dts and (
https://github.com/vazco/uniforms ,
https://github.com/rjsf-team/react-jsonschema-form ) or
https://github.com/mulesoft-labs/json-ld-schema that would be usable offline in frequent, automated builds?
  - Is there a good way to get {pySHACL,} data validation messages to display in an HTML+JS form?
  - Can SHACL validation also be done in JS in a browser; for live form validation without server load?
  - What are the standards for returning SHACL validation results in RDF over HTTP?
- LDP and/or / instead_of SPARQL:
  TIL about "A LDP server in Python3 using asyncio, aiohttp and api_hour" named glutton:
  - name: glutton
   > Two Flask web-apps for quickly setting up a SPARQL 1.0 Endpoint or a LOD app for RDFLib
   >Â
   > This module contains a small Python module which is intended to be added (imported) into a Python Flask installation to add a small library of Renderer classes which can be used to handle requests and return responses in a manner consistent with Linked Data principles of operation.
   > The intention is to make it easy to "Linked Data-enable" web APIs.
These for Django would be cool; it'd be great to be able to use the batteries included in the framework with Linked Data data sources instead of SQL to Object models.