Not logged in : Login
(Sponging disallowed)

About:     Goto   Sponge   NotDistinct   Permalink

An Entity of Type : sioc:Post, within Data Space : associated with source document(s)
QRcode icon

Date Created
  • 2019-08-02T22:16:49.322Z
Date Modified
  • 2019-08-19T14:53:59.224Z
described by
has container

    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

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


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


    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.


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


    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 critical loosely-coupling that’s mandatory regarding identity, identification, authentication, authorization, and storage.


post number
  • 1
reply count
  • 0
quote count
  • 0
incoming link count
  • 25
  • 121
topic id
  • 1116
topic slug
  • deceptively-simple-data-entry-form
is container of of
Faceted Search & Find service v1.17_git51 as of Jun 26 2020

Alternative Linked Data Documents: PivotViewer | ODE     Content Formats:       RDF       ODATA       Microdata      About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 08.03.3318 as of Jul 10 2020, on Linux (x86_64-generic-linux-glibc25), Single-Server Edition (378 GB total memory)
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2020 OpenLink Software