## 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:
http://www.web2py.com/books/default/chapter/29/07/forms-and-validators
- Django ModelForms (and class-based views) are unfortunately somewhat
tightly coupled to the Django ORM:
https://docs.djangoproject.com/en/3.2/topics/forms/modelforms/
"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:
https://www.django-rest-framework.org/api-guide/validators/
https://www.django-rest-framework.org/api-guide/serializers/
- 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
- From
https://github.com/schemaorg/schemaorg/issues/2790#issuecomment-839263042 re:
schema validation [of template output in CI test runs] :
> 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?
- https://github.com/RDFLib/pySHACL#python-module-use
- 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:
- From https://www.w3.org/wiki/LDP_Implementations
TIL about "A LDP server in Python3 using asyncio, aiohttp and api_hour"
named glutton:
- name: glutton
- source: https://github.com/CommonsDev/glutton
- description: "-
https://github.com/CommonsDev/glutton/blob/develop/glutton/glutton/__init__.py\n-
"
- From https://github.com/RDFLib?type=source but not
https://rdflib.dev/#rdflib-family-of-packages :
- https://github.com/RDFLib/rdflib-web
> Two Flask web-apps for quickly setting up a SPARQL 1.0 Endpoint or
a LOD app for RDFLib
- https://github.com/RDFLib/pyLDAPI
>
> 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.
On Sun, May 30, 2021, 15:18 [email protected] <
[email protected]> wrote:
> Thank you for the confirmation and the additions.
> Thinking about these DOS attacks will be an issue for all implementations
> imo; so I will not start taking this a major criterion.
>
> Local graph queries and the RDF store can be used behind this sparql
> endpoint. Queries supply optionally a graph name in the query or as
> parameter.
>
> I have already developed RDF model driven apps using web2py. I would like
> start using py4web (successor of web2py) for the sparql endpoint because of
> the easy use of py4web. Py4web is rather new but I think it will be
> sufficient mature within 1 year. Now we have a momentum for RDF based
> solutions. This type of solutions require always software development. A
> productive Python ecosystem will lower the effort required for initial RDF
> model driven applications because specific query might return specific
> output like charts, graphs, json or formatted tables using specific
> vocabulaires.
>
> My experience is also with TQ TB Composer and TB EDG. My wep2py apps used
> EDG as a sparql endpoint for both ontology and data store. TB EDG use
> GraphQL for form generation; I have been using pydal for instant form
> generation and data validation based on SHACL.
>
> I am also in contact with the py4web community for their interest in this
> initiative.
>
>
> On Sunday, May 30, 2021 at 4:38:38 PM UTC+2 [email protected] wrote:
>
>> Rdflib has support for SPARQL queries on local graphs and remote SPARQL
>> endpoints, but doesn't specify a framework to use to send results back over
>> HTTP per e.g. SPARQL 1.1 UPDATE or SPARQL 1.1 Graph Store HTTP Protocol.
>>
>>
>> https://rdfextras.readthedocs.io/en/latest/working_with.html#working-with-sparql
>>
>> SPARQL 1.1 Update
>> https://www.w3.org/TR/sparql11-update/
>>
>> SPARQL 1.1 Graph Store HTTP Protocol
>> https://www.w3.org/TR/sparql11-http-rdf-update/
>>
>> FWIU, LDP is an alternate way to share subgraphs over HTTP which
>> specifies how to do pagination, where SPARQL does not and something should
>> enforce a default and a maximum LIMIT clause.
>>
>> What does this query do when run by many users concurrently?
>>
>> SELECT ?s, ?p, ?o LIMIT 1000000000000;
>>
>> That's okay though, because like any database can be trivially DOS'd if
>> the DB interface is exposed to end users, right?
>>
>> So, there is not an opportunity to eliminate the web application server
>> tier because SPARQL endpoints cannot be exposed to end users without
>> creating a Denial-of-Service vulnerability.
>>
>> Which framework should a reference e.g. LDP or SOLID (LDP+[...])
>> implementation be written for?
>>
>> - Django, on top of DRF
>> - Flask, because I want to reinvent auth/authz for every implementation
>> - Flask, because it's more async
>> - ?
>>
>>
>>
>> On Sun, May 30, 2021, 06:59 [email protected] <
>> [email protected]> wrote:
>>
>>> As far as I know no Python based sparql-endpoint (like Fuseki,
>>> https://jena.apache.org/documentation/fuseki2/) implementations exist.
>>>
>>> Do (previous) initiatives exist with this goal?
>>>
>>> --
>>> http://github.com/RDFLib
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "rdflib-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/rdflib-dev/067098ee-f08e-424c-9cdf-d9e234f635c3n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rdflib-dev/067098ee-f08e-424c-9cdf-d9e234f635c3n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> http://github.com/RDFLib
> ---
> You received this message because you are subscribed to the Google Groups
> "rdflib-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rdflib-dev/75b8b124-da49-4b34-96e5-6ef361eaf047n%40googlegroups.com
> <https://groups.google.com/d/msgid/rdflib-dev/75b8b124-da49-4b34-96e5-6ef361eaf047n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
http://github.com/RDFLib
---
You received this message because you are subscribed to the Google Groups
"rdflib-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/rdflib-dev/CACfEFw9hzMHr4LA_Nv00pZAueh3hXyNY3OFPxcpk6BTLvsFCwg%40mail.gmail.com.
