Re: Safe manipulation of RDF data (from semantic-web)

Looking at your first example, looks like that and this acl version work 
both?

So as with your first example:

/person/basic_access/{id}
--

:BasicPersonAccessItem a ldt:Template ;
     ldt:match "/person/basic_access/{id}" ;
     ldt:query :ConstructBasicPerson ;
  
----
/person/admin_access/{id}
--
:AdminPersonAccessItem a ldt:Template ;
     ldt:match "/person/admin_access/{id}" ;
     ldt:query :ConstructFullPerson ;


  
And this acl example

/person/{agent}/{id}
--
:PersonAccessItem a ldt:Template ;
     ldt:match "/person/{agent}/{id}" ;
     ldt:query :ConstructPerson ;
...
  

ACL example sure is more refined since you can define the access levels 
in the ACL data.


On 13/09/2019 16:25, Martynas Jusevičius wrote:
> Well if you only have one kind of person resources with a single URI
> pattern, then you cannot select (match) different LDT templates.
> That is because an LDT template maps one URI pattern to one SPARQL
> command. The matching process is not looking into the SPARQL query
> results at all, only at the request URI and the application's LDT
> ontology.
>
> I think you can solve this with a single query though. What we do is
> provide the URI of the requesting agent as a query binding, e.g.
> ?agent variable. Something like
>
> :ConstructPerson a sp:Construct ;
>      sp:text """
> PREFIX  foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX  acl:  <http://www.w3.org/ns/auth/acl#>
>
> CONSTRUCT
>    {
>      ?this a foaf:Person .
>      ?this foaf:name ?name .
>      ?this ?p ?o .
>    }
> WHERE
>    {   { ?this  a                     foaf:Person ;
>                 foaf:name             ?name
>        }
>      UNION
>        { GRAPH <acl>
>            { ?auth  acl:accessTo  ?this ;
>                   acl:agent ?agent .
>            }
>          ?this  ?p  ?o
>        }
>    }
>      """ ;
>      rdfs:isDefinedBy : .
>
> The idea is that the person query always returns "basic" properties,
> and adds all properties *only* if the agent ?agent has an
> authorization to access the requested resource ?this.
> This approach requires that the query has access to the ACL data,
> which I have indicated here as GRAPH <acl>. The actual pattern for
> authorization check will probably be more complex of course.
> It also requires that the authentication mechanism can provide the URI
> of the agent.
>
> I hope I got what you meant :)
>
> On Fri, Sep 13, 2019 at 2:58 PM Mikael Pesonen
> <mikael.pesonen@lingsoft.fi> wrote:
>>
>> Ah, I might have explained our case bit vaguely. So I just meant that we
>> have in RDF data one kind of person resources, and
>> depending on the access rights in the application, you are allowed to
>> see different portions of that person's data.
>> Basic user sees only the name, for example, and admin user is allowed to
>> see all data. This is handled by selecting different template for basic
>> user and admin, right?
>>
>>
>>
>> On 13/09/2019 15:52, Martynas Jusevičius wrote:
>>> Mikael,
>>>
>>> this is related to hierarchical URIs:
>>> http://patterns.dataincubator.org/book/hierarchical-uris.html
>>>
>>> In your case, the question is how you have organized the
>>> collections/items of basic and admin persons in your dataset.
>>>
>>> One option is that both "basic persons" and "admin persons" belong to
>>> the same collection and have a single URI pattern: /persons/{id}
>>> In this case you cannot tell if resource /persons/12345 is a "basic
>>> person" or "admin person" just from its URI. You need to dereference
>>> it and the look into RDF types and properties.
>>>
>>> Another option is that you treat them as belonging to separate
>>> collections, for example: /persons/{id} and /admins/{id}
>>> In this case you can easily tell if a resource is a "basic person" or
>>> an "admin person" already from its URIs.
>>>
>>> Linked Data Templates are best suited for this second case, where URI
>>> space is subdivided into hierarchies based on entity types. That makes
>>> it easy to define URI templates that match precisely the set of
>>> resources that you want.
>>>
>>> Does it make it clearer?
>>>
>>> On Fri, Sep 13, 2019 at 2:08 PM Mikael Pesonen
>>> <mikael.pesonen@lingsoft.fi> wrote:
>>>> Hi Martynas,
>>>>
>>>> thank you for the examples, GET seems clear now.
>>>>
>>>> Good point about the person / document. We probably end up with three
>>>> kind of resources: actual object, admin record (who last modified etc),
>>>> and web page or another document about the object.
>>>>
>>>> Just one question: what did you mean by
>>>>
>>>> "If you cannot distinguish "basic person" from "admin person" by their
>>>> URIs"?
>>>>
>>>>
>>>> We are not quite there yet with updates, so we might have questions
>>>> later about those.
>>>>
>>>> Br,
>>>> Mikael
>>>>
>>>> On 11/09/2019 18:45, Martynas Jusevičius wrote:
>>>>> Hi Mikael,
>>>>>
>>>>> thanks for reaching out.
>>>>>
>>>>> There is more information on LDT in the AtomGraph Processor wiki, more
>>>>> specifically: https://github.com/AtomGraph/Processor/wiki/Linked-Data-Templates
>>>>>
>>>>> The matching is based on URIs: relative request URI is being matched
>>>>> against the ldt:match values of templates in the ontology.
>>>>>
>>>>> Then, from the matching template (if there is any), the SPARQL command
>>>>> is retrieved using either ldt:query or ldt:update (depending on the
>>>>> HTTP request method).
>>>>>
>>>>> To address your example, templates and queries could look like this:
>>>>>
>>>>> :BasicPersonItem a ldt:Template ;
>>>>>        ldt:match "/person/basic/{id}" ;
>>>>>        ldt:query :ConstructBasicPerson ;
>>>>>        rdfs:isDefinedBy : .
>>>>>
>>>>> :ConstructBasicPerson a sp:Construct ;
>>>>>        sp:text """
>>>>>        PREFIX  foaf: <http://xmlns.com/foaf/0.1/>
>>>>>
>>>>>        CONSTRUCT
>>>>>        {
>>>>>            ?this a foaf:Person ;
>>>>>                foaf:name ?name .
>>>>>        }
>>>>>        {
>>>>>            ?this a foaf:Person ;
>>>>>                foaf:name ?name .
>>>>>        }
>>>>>        """ ;
>>>>>        rdfs:isDefinedBy : .
>>>>>
>>>>> :AdminPersonItem a ldt:Template ;
>>>>>        ldt:match "/person/admin/{id}" ;
>>>>>        ldt:query :ConstructAdminPerson ;
>>>>>        rdfs:isDefinedBy : .
>>>>>
>>>>> :ConstructAdminPerson a sp:Construct ;
>>>>>        sp:text """
>>>>>        CONSTRUCT WHERE
>>>>>        {
>>>>>            ?this ?p ?o
>>>>>        }
>>>>>        """ ;
>>>>>        rdfs:isDefinedBy : .
>>>>>
>>>>> "Basic person" query retrieves only name and type, "admin person"
>>>>> query retrieves all properties.
>>>>> This example requires that basic and admin person resources can be
>>>>> differentiated by their URIs, i.e. "/person/basic/{id}" vs
>>>>> "/person/admin/{id}".
>>>>>
>>>>> It also assumes that persons are documents (since they can be
>>>>> dereferenced over HTTP), which is not kosher re. httpRange-14 [1]. A
>>>>> better solution would have separate resources for persons e.g. using
>>>>> hash URIs such as #this) and explicitly connect them to documents
>>>>> using an RDF property. We use foaf:primaryTopic/foaf:isPrimaryTopicOf.
>>>>> But this is a whole topic on its own.
>>>>>
>>>>> If you cannot distinguish "basic person" from "admin person" by their
>>>>> URIs, you could also have a template that matches both and maps to a
>>>>> single query. The question is then whether you can differentiate which
>>>>> properties to return using a single query.
>>>>>
>>>>> Does this help?
>>>>>
>>>>>
>>>>> [1] https://www.w3.org/2001/tag/group/track/issues/14
>>>>>
>>>>> Martynas
>>>>> atomgraph.com
>>>>>
>>>>> On Wed, Sep 11, 2019 at 11:21 AM Mikael Pesonen
>>>>> <mikael.pesonen@lingsoft.fi> wrote:
>>>>>> Hi Martynas,
>>>>>>
>>>>>> we have a proprietary implementation now:
>>>>>>
>>>>>> js/React app generates a custom json out of form data. That is sent
>>>>>> (with a template id) to also custom proxy, which converts the json into
>>>>>> SPARQL using pre made templates. SPARQL is then queried on Apache Jena.
>>>>>>
>>>>>> Now we would like to replace all custom bits with one ore more standards.
>>>>>>
>>>>>> Is it possible to have any kind of templates with LDT? For example
>>>>>> "person_basic" and "person_admin",
>>>>>> where admin contains more properties of a person?
>>>>>>
>>>>>> I'm still having trouble to understand how the SPARQL template is
>>>>>> selected with LDT.
>>>>>>
>>>>>> Br,
>>>>>> Mikael
>>>>>>
>>>>>> On 10/09/2019 15:50, Martynas Jusevičius wrote:
>>>>>>> Hey Mikael,
>>>>>>>
>>>>>>> we have a simple example here: https://github.com/AtomGraph/Processor#example
>>>>>>>
>>>>>>> Do you have some specific use case in mind? If you can share it, I can
>>>>>>> probably look into it.
>>>>>>>
>>>>>>> There is a Community Group for Linked Data Templates which includes a
>>>>>>> mailing list: https://www.w3.org/community/declarative-apps/
>>>>>>>
>>>>>>> Martynas
>>>>>>> atomgraph.com
>>>>>>>
>>>>>>> On Tue, Sep 10, 2019 at 1:27 PM Mikael Pesonen
>>>>>>> <mikael.pesonen@lingsoft.fi> wrote:
>>>>>>>> In the example there is the GET request
>>>>>>>>
>>>>>>>> GET /people/Berners-Lee?g=http%3A%2F%2Flinkeddatahub.com%2Fgraphs%2Fc5f34fe9-0456-48e8-a371-04be71529762 HTTP/1.1
>>>>>>>>
>>>>>>>>
>>>>>>>> Often you want to query different amounts of data depending of the case. Sometimes for example, person name is enough, other time you want all the triples (DESCRIBE).
>>>>>>>> How do you specify here the context?
>>>>>>>>
>>>>>>>> BTW is there a dedicated forum for discussing Linked Data Templates?
>>>>>> --
>>>>>> Lingsoft - 30 years of Leading Language Management
>>>>>>
>>>>>> www.lingsoft.fi
>>>>>>
>>>>>> Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books
>>>>>>
>>>>>> Mikael Pesonen
>>>>>> System Engineer
>>>>>>
>>>>>> e-mail: mikael.pesonen@lingsoft.fi
>>>>>> Tel. +358 2 279 3300
>>>>>>
>>>>>> Time zone: GMT+2
>>>>>>
>>>>>> Helsinki Office
>>>>>> Eteläranta 10
>>>>>> FI-00130 Helsinki
>>>>>> FINLAND
>>>>>>
>>>>>> Turku Office
>>>>>> Kauppiaskatu 5 A
>>>>>> FI-20100 Turku
>>>>>> FINLAND
>>>>>>
>>>> --
>>>> Lingsoft - 30 years of Leading Language Management
>>>>
>>>> www.lingsoft.fi
>>>>
>>>> Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books
>>>>
>>>> Mikael Pesonen
>>>> System Engineer
>>>>
>>>> e-mail: mikael.pesonen@lingsoft.fi
>>>> Tel. +358 2 279 3300
>>>>
>>>> Time zone: GMT+2
>>>>
>>>> Helsinki Office
>>>> Eteläranta 10
>>>> FI-00130 Helsinki
>>>> FINLAND
>>>>
>>>> Turku Office
>>>> Kauppiaskatu 5 A
>>>> FI-20100 Turku
>>>> FINLAND
>>>>
>> --
>> Lingsoft - 30 years of Leading Language Management
>>
>> www.lingsoft.fi
>>
>> Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books
>>
>> Mikael Pesonen
>> System Engineer
>>
>> e-mail: mikael.pesonen@lingsoft.fi
>> Tel. +358 2 279 3300
>>
>> Time zone: GMT+2
>>
>> Helsinki Office
>> Eteläranta 10
>> FI-00130 Helsinki
>> FINLAND
>>
>> Turku Office
>> Kauppiaskatu 5 A
>> FI-20100 Turku
>> FINLAND
>>

-- 
Lingsoft - 30 years of Leading Language Management

www.lingsoft.fi

Speech Applications - Language Management - Translation - Reader's and Writer's Tools - Text Tools - E-books and M-books

Mikael Pesonen
System Engineer

e-mail: mikael.pesonen@lingsoft.fi
Tel. +358 2 279 3300

Time zone: GMT+2

Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND

Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND

Received on Friday, 13 September 2019 13:55:41 UTC