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

I meant the first and the ACL examples as alternatives, but yes you
can combine the approaches as well. Again, depends mostly on your URIs
- and are able to change their pattern?

I think it would help if you could show some RDF data that represents
your case (does not have to be the actual person data :)) Either paste
inline or as a Gist if it's larger.

Re. ACL, we use a filter in our LinkedDataHub platform that checks ACL
access before the actual LDT request is invoked. And if query results
need to depend on the access level, we reference the ACL dataset as I
showed in the example.

Martynas

On Fri, Sep 13, 2019 at 3:55 PM Mikael Pesonen
<mikael.pesonen@lingsoft.fi> wrote:
>
>
> 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 Saturday, 14 September 2019 22:02:39 UTC