Re: shapes, forms, and footprints for building Linked Data apps

> On Jun 17, 2019, at 12:15 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
>> Other extensions address the fact that a view presentation of data may need to be different from the edit presentation, provide  instructions for embedding and creating “related” resources (e.g., a person may have multiple addresses with people and addresses being separate related resource, from a form perspective, a user will want to see and create addresses as part of a person’s form), etc.
> 
> These might probably go into what we call “footprints”.


I read about footprints and they seem to be about creating new resources or, more broadly, new RDF terms. When one edits forms one could be creating a new RDF term. However, the requirement I was describing exists even if you are simply viewing information.

The way I understood footprints is that they provide information as to where to insert newly created data and how to form URIs for the new terms.

By way of example questions, the document says:

In a linked data world, triples are stored at the document of the subject, or of the object, or both. In this world, the critical things are then

How to we generate the URI for a new node?
Is a given triple forward or backward linked, or both?
What kind of indexes have to be updated?
The way we handle this is as follows:

1. In EDG, we have several mechanisms for defining how to generate a URI.

There is an extension (a custom defined SHACL constraint) that lets us specify that a URI should be created by using a given namespace and then appending a value of some specific property.  This can be declared as part of a shape. This could be something else like a combination of values of 2 properties with a separator between them or a UUID.

It is also quite common for users to simply chose a single URI generation policy for the whole graph meaning that any new resource inserted into a graph will have a URI generated based on a selected policy. The policy (we call it a URI construction rule) would then be specified at a graph level. By default, there is a choice of combining a selected namespace (often, a default namespace) with either a label or an auto-generated UUID or a counter. As an additional option for any of these, they could chose to append after a namespace an acronym for a class or a full class name and then let’s say a UUID. We also let users plugin a custom URI construction algorithm.

There is a question of how to know what graph to put new triples into. We do create new triples in different graphs, it is part of the APIs as an input parameter called “update graph”. It is determined based on the user’s context. It could be specified declaratively, but I do not think that currently it is.

2. We generate a link in only one direction - as specified by the property used in the property shape. If it is an inverse link (uses sh:InversePropertyPath), then it is shows a triple in the inverse direction. Any new triple will still be of the :s :p :o form, not in the :o :inv-p :s form even if the form seems to indicate otherwise. 

3. I am not fully certain what this is about

If new data is added, indexes should be updated. Some updates must be immediate. Some would tolerate certain time lapse between the change and index update.