- From: Mikael Pesonen <mikael.pesonen@lingsoft.fi>
- Date: Mon, 16 Sep 2019 12:27:10 +0300
- To: Martynas Jusevičius <martynas@atomgraph.com>
- Cc: public-declarative-apps@w3.org
Here is a sample data: <https://resource.lingsoft.fi/286c384d-cd5c-4887-9b85-94c0c147f709> a foaf:Person ; vcard:family-name "Pesonen" ; vcard:fn "Mikael Pesonen" ; vcard:given-name "Mikael" ; vcard:hasEmail <https://resource.lingsoft.fi/cf9b02b7-bd0d-486e-b0d9-da1464e27d2e> , <https://resource.lingsoft.fi/5c04aa23-6c42-44a1-9ac9-69ee255ac170> ; vcard:hasGender vcard:Male ; vcard:hasInstantMessage <https://resource.lingsoft.fi/4aa01d37-744c-4964-a794-d997aa376584> ; vcard:hasPhoto <https://resource.lingsoft.fi/8f4a4ddd-43c2-4e27-8ed7-996dd00e939c> ; vcard:hasTelephone <https://resource.lingsoft.fi/3755ed0c-81b7-430e-92a0-16fc80ba41b4> ; org:basedAt <https://resource.lingsoft.fi/b48a0820-6921-43fc-a346-e72397265bbe> ; org:memberOf <https://resource.lingsoft.fi/810dfbff-e6fb-458a-b27d-3726a27e5109> ; foaf:account <https://resource.lingsoft.fi/2f0aa772-f845-4f43-b607-dc65ff66b9aa> ; <https://resource.lingsoft.fi/cf9b02b7-bd0d-486e-b0d9-da1464e27d2e> a vcard:Email , vcard:Work ; rdfs:label "***@lingsoft.fi" ; vcard:hasValue <mailto:***@lingsoft.fi> . So most of the person's values are resources and every resource has id of type https://resource.lingsoft.fi/<UUID>. Mikael On 15/09/2019 01:02, Martynas Jusevičius wrote: > 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 >> -- 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 Monday, 16 September 2019 09:27:40 UTC