Deceptively Simple Data Entry Form

Virtuoso Universal Server Tips, Tricks, and HowTos
, , , ,
1

This simple Data Entry form 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; and 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

In addition, the form should provide abstraction that enables data to be saved to either a Database Management System (DBMS) or a Filesystem.

DBMS

SPARQL-compliant DBMS where Data is written to a Database hosted Document (a/k/a as a Named Graph)

Filesystem

Example Implementation

For our purposes, 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.

deceptively-simple-data-entry-form-multilingual
deceptively-simple-data-entry-form-multilingual1244×613 81.9 KB

Solution

Using the following open standards, it is possible to build a powerful form comprising three input fields that address the challenge posed.

  • HTML5 — for presentation skeleton
  • CSS — for presentation decoration
  • Javascript — for scripted orchestration
  • Resource Description Framework — for Entity Relationship Modeling
  • URIs — for Identity
  • HTTP — for Document Interactions
  • HTTP URIs — for Entity Identification
  • SPARQL — for Data Creation, Querying, and Deletion
  • Linked Data Profile (LDP) extensions to HTTP for granular operations on Documents of different types (e.g., Files and Folders)

What’s Happening Here?

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) 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 Value 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

Conclusion

As demonstrated in this post, you can create “deceptively simple” data entry forms using the combined power delivered by existing open standards, without being distracted by frameworks that can skew what’s possible at first blush.

Naturally, once the core understanding and skeleton is in place, your favorite framework can be used to embellish most of the aesthetics of the core application without compromising the critical and mandatory loose-coupling of identity, identification, authentication, authorization, and storage.

Related

2

The latest incarnation of this Data Entry form includes reasoning and inference functionality. Thus, it enables the use of reasoning & inference to solve the question:

What is the name of an entity identified by :i, given that it is the same entity as the one identified by :me?

Expressed in RDF-Turtle notation, the data for the situation is expressed as:

PREFIX : <#> 

:me foaf:name  "Kingsley Idehen" . 
:me owl:sameAs :i .

The actual question and solution expressed as a SPARQL Query:

DEFINE input:same-as "yes" 

PREFIX : <urn:records:test#>
SELECT DISTINCT ?o 
FROM <urn:records:test> 
WHERE { :i foaf:name ?o }

Live Query Result Page

Here’s a screencast demonstration:

3

Here’s a screencast demonstrating how reasoning and inference applied to the semantics of an owl:InverseFunctional property (e.g., schema:sameAs) also reconciles information for a common entity identified using two different identifiers. In this case, reasoning and inference is triggered by a built-in inference rule that designates relationship types such as schema:sameAs, foaf:mbox as being owl:InverseFunctional property types.

SPARQL Query demonstrating effect.

DEFINE input:inference 'urn:ifp:inference:rule' 
PREFIX : <urn:records:test#>
SELECT DISTINCT ?o
FROM <urn:records:test> 
WHERE { :i foaf:name ?o }

Live Query Results Page

Related