Simple Data Entry Form for Filesystems or DBMS Interaction

Build a Solid App Ideas for Solid Apps
1

Problem

Applications need to provide their end-users with full control over profile information in order to negate the deeply complex burden of end-user privacy – a major challenge currently afflicting all Web Applications.

Solution

HTML5, CSS, and Javascript based Application that leverages the Solid Authentication Client (solid-auth-client) component for Identity Authentication that loosely-bound to a variety of OpenID Connect compliant Identity Providers.

Solution Example

A simple Data Entry Form that satisfies the following conditions.

  • Supports the age-old Model, View, and Controller (MVC) pattern — where Entity->Attributes->Values (EAV) oriented 3-Tuples handle the Model, HTML and CSS handle the View, Javascript handles the Controller — without the usual imposition of some framework on the process before you get started
  • Supports References of Literal Values for input — including language tagged literals for multilingual labeling and general annotation
  • Loosely-couples Identity, Identification, Authentication, Authorization, and Storage
  • Discovers default Storage Preferences via User Profile information while also allowing defaults to be overruled
  • Enables data to be saved to either a Database Management System (DBMS) or a Filesystem (a Solid Pod).

Form Usage Example

For this exercise, the system has to be capable of productively enabling a user to describe the concept “Linked Data”, along the following lines:

  1. Concept Identifier — an HTTP URI from DBpedia
  2. Preferred Label — using skos:prefLabel and language-tagged literals covering at least three national languages, e.g., English, French, German, Chinese, Japanese, etc.

An example solution is depicted in the image below.

54%20AM
54%20AM1125×556 33.4 KB

Component Breakdown

SPARQL Query Service Endpoint

Across DBMS and Filesystem operations, this service handles the following operations:

  • Data Entry Validation — accepted Object Field values for a given Predicate Field input e.g., foaf:name accepts a Literal Value while owl:sameAs accepts a Reference Value
  • Data Definition (DDL) and Data Manipulation (DML) operations

Document Names

A default Document Name is determined at application initialization time. This identifier is determined by looking up preferences from the application-users profile document after successful login, or set to a preset value associated with an Attribute-based Access Control (ABAC or WebACLs) associated with the default SPARQL Query Service endpoint.

This setup also implies that changing the target SPARQL Query Service endpoint requires existence of a default Document Name and associated ABAC-ACL for smooth operation.

For DBMS mode, the Data Source Name references the target of SPARQL INSERT and DELETE operations scoped to a DBMS hosted Document Name (or Named Graph in SPARQL parlance).

For Filesystem mode, the Data Source Name is a reference to an actual RDF-Turtle Document (default is “mydata.ttl”) associated with a default folder name.

Input Field Values Handling

  • A single word entry is treated as a Relative URIs scoped to the deployment document are presumed for single word values entered into any of the input files
  • CURIES are accepted, if targeting a Virtuoso instance, due to the fact that this DBMS includes preloaded namespaces per DBMS instance

Subject Field Values

  • Must be a reference (absolute or relative URI which may be quoted [using <>] or unquoted) or Blank Node (i.e., literals aren’t accepted)

Predicate Field Values

  • Must be a reference

Object Field Values

Acceptable values include

  • References (as per what’s outlined above regarding Subject and Predicate input fields)
  • Literal Values (Unquoted phrases or quoted words)
  • Typed Literal Values (e.g., “{literal}”^^xsd:{data-type})
  • Language Tagged Quoted Literal Values (e.g., “{word-or-phrase}”@en
  • Blank Nodes

Important Note regarding Solid Pods

  • App currently sets a “mydata.ttl” default document in your inbox folder – this is a private document, so the Virtuoso Sponger Middlerware can’t access it when trying to display the effects of your insert or delete operations

  • You can replace the default target document name with a URL that identifies any document in your Solid Pod – e.g., one that provides read access to public, if you want to enjoy the effects of seeing your changes in the data table, as they occur.

Conclusion

You can use Solid to simplify the development and deployment of Single Page Applications where end-user privacy is protected by loosely-coupling identity, identification, authentication, authorization, and storage.

As demonstrated, a Single-Page Application can use the power of Linked Data to determine end-user preferences (e.g., storage) by looking up WebID-Profile documents via WebID de-reference.

Related

4 Likes
2

Nicely done!

3

Thanks!

It took the combined effort of a very determined intern and support from the OpenLink Team to navigate all the distracting riddles associated with this quest :slight_smile:

This is also a nice QA tool regarding Solid Authentication and WebACLs too! Really saves time etc…