- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Wed, 18 Sep 2019 12:20:13 +0200
- To: Mikael Pesonen <mikael.pesonen@lingsoft.fi>
- Cc: public-declarative-apps@w3.org
Oops, I'll CC the list again :)
Could you try mounting log4j.properties as well, like in the example?
That should give you debug output in the container.
Also a good idea to validate the ontology's Turtle syntax (or any RDF
config really) after any changes, just to be sure. There's a handy
online tool: http://ttl.summerofcode.be
BTW you can also do docker pull atomgraph/processor, I just released
an updated version that allows killing the container gracefully with
Ctrl+C.
On Wed, Sep 18, 2019 at 12:12 PM Mikael Pesonen
<mikael.pesonen@lingsoft.fi> wrote:
>
>
> Thanks! Now I think I have the correct command line
>
> sudo docker run --rm -p 8090:8090 -e
> ENDPOINT="https://query.wikidata.org/bigdata/namespace/wdq/sparql" -e
> GRAPH_STORE="https://query.wikidata.org/bigdata/namespace/wdq/service"
> -e
> ONTOLOGY="https://github.com/AtomGraph/Processor/blob/develop/examples/wikidata#"
> -v
> "/home/text/cases/nimisampo/proxy/wikidata.ttl":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/org/wikidata/ldt.ttl"
> -v
> "/home/text/cases/nimisampo/proxy/location-mapping.n3":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/custom-mapping.n3"
> atomgraph/processor
>
> When testing I get
>
> >> curl -v http://localhost:8090/birthdays
>
> * Trying ::1...
> * Connected to localhost (::1) port 8090 (#0)
> > GET /birthdays HTTP/1.1
> > Host: localhost:8090
> > User-Agent: curl/7.47.0
> > Accept: */*
> >
> * Recv failure: Connection reset by peer
> * Closing connection 0
> curl: (56) Recv failure: Connection reset by peer
>
>
> Do you have and idea what could be the issue? In docker output there
> seems to be no errors:
>
> @prefix lm: <http://jena.hpl.hp.com/2004/08/location-mapping#> .
>
> [] lm:mapping
>
> [ lm:name "https://www.w3.org/ns/ldt#"
> ; lm:altName
> "com/atomgraph/processor/ldt.ttl" ] ,
> [ lm:name "https://www.w3.org/ns/ldt/core/domain#"
> ; lm:altName "com/atomgraph/processor/c.ttl" ] ,
> [ lm:name "https://www.w3.org/ns/ldt/core/templates#"
> ; lm:altName "com/atomgraph/processor/ct.ttl" ] ,
> [ lm:name "https://www.w3.org/ns/ldt/named-graphs/templates#"
> ; lm:altName "com/atomgraph/processor/ngt.ttl" ] ,
> [ lm:name "https://www.w3.org/ns/ldt/document-hierarchy/domain#"
> ; lm:altName "com/atomgraph/processor/dh.ttl" ] ,
> [ lm:name "https://www.w3.org/ns/ldt/topic-hierarchy/templates#"
> ; lm:altName "com/atomgraph/processor/tht.ttl" ] ,
> [ lm:name "http://rdfs.org/sioc/ns#"
> ; lm:altName
> "com/atomgraph/processor/sioc.owl" ] ,
> [ lm:name "http://rdfs.org/ns/void#"
> ; lm:altName
> "com/atomgraph/processor/void.owl" ] ,
> [ lm:name "http://www.w3.org/2011/http#"
> ; lm:altName
> "com/atomgraph/processor/http.owl" ] ,
> [ lm:name "http://www.w3.org/2011/http"
> ; lm:altName
> "com/atomgraph/processor/http.owl" ] ,
> [ lm:name "http://www.w3.org/2011/http-statusCodes#"
> ; lm:altName
> "com/atomgraph/processor/http-statusCodes.rdf" ] ,
> [ lm:name "http://www.w3.org/2011/http-statusCodes"
> ; lm:altName
> "com/atomgraph/processor/http-statusCodes.rdf" ] ,
> [ lm:name "http://www.w3.org/ns/sparql-service-description#"
> ; lm:altName "com/atomgraph/processor/sparql-service.owl" ] ,
> [ lm:name "http://xmlns.com/foaf/0.1/"
> ; lm:altName
> "com/atomgraph/processor/foaf.owl" ] ,
> [ lm:name "http://spinrdf.org/sp#"
> ; lm:altName "etc/sp.ttl" ] ,
> [ lm:name "http://spinrdf.org/sp"
> ; lm:altName "etc/sp.ttl" ] ,
> [ lm:name "http://spinrdf.org/spin#"
> ; lm:altName "etc/spin.ttl" ] ,
> [ lm:name "http://spinrdf.org/spin"
> ; lm:altName "etc/spin.ttl" ] ,
> [ lm:name "http://spinrdf.org/spl#"
> ; lm:altName "etc/spl.spin.ttl" ] ,
> [ lm:name "http://spinrdf.org/spl"
> ; lm:altName "etc/spl.spin.ttl" ]
> .
>
> ... html for a github page ...
>
> 18-Sep-2019 09:57:42.303 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server
> version: Apache Tomcat/8.0.52
> 18-Sep-2019 09:57:42.305 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server
> built: Apr 28 2018 16:24:29 UTC
> 18-Sep-2019 09:57:42.306 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server
> number: 8.0.52.0
> 18-Sep-2019 09:57:42.306 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS
> Name: Linux
> 18-Sep-2019 09:57:42.306 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS
> Version: 4.4.0-148-generic
> 18-Sep-2019 09:57:42.306 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log
> Architecture: amd64
> 18-Sep-2019 09:57:42.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Java
> Home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> 18-Sep-2019 09:57:42.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM
> Version: 1.8.0_171-8u171-b11-1~deb9u1-b11
> 18-Sep-2019 09:57:42.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM
> Vendor: Oracle Corporation
> 18-Sep-2019 09:57:42.307 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log
> CATALINA_BASE: /usr/local/tomcat
> 18-Sep-2019 09:57:42.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log
> CATALINA_HOME: /usr/local/tomcat
> 18-Sep-2019 09:57:42.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument:
> -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties
> 18-Sep-2019 09:57:42.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> 18-Sep-2019 09:57:42.308 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djdk.tls.ephemeralDHKeySize=2048
> 18-Sep-2019 09:57:42.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> 18-Sep-2019 09:57:42.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dignore.endorsed.dirs=
> 18-Sep-2019 09:57:42.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.base=/usr/local/tomcat
> 18-Sep-2019 09:57:42.309 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.home=/usr/local/tomcat
> 18-Sep-2019 09:57:42.310 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
> 18-Sep-2019 09:57:42.310 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
> based Apache Tomcat Native library 1.2.16 using APR version 1.5.2.
> 18-Sep-2019 09:57:42.310 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false],
> random [true].
> 18-Sep-2019 09:57:42.314 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized (OpenSSL 1.1.0f 25 May 2017)
> 18-Sep-2019 09:57:42.387 INFO [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["http-apr-8080"]
> 18-Sep-2019 09:57:42.394 INFO [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["ajp-apr-8009"]
> 18-Sep-2019 09:57:42.398 INFO [main]
> org.apache.catalina.startup.Catalina.load Initialization processed in 451 ms
> 18-Sep-2019 09:57:42.432 INFO [main]
> org.apache.catalina.core.StandardService.startInternal Starting service
> Catalina
> 18-Sep-2019 09:57:42.432 INFO [main]
> org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> Engine: Apache Tomcat/8.0.52
> 18-Sep-2019 09:57:42.446 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deploying
> configuration descriptor /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml
> 18-Sep-2019 09:57:43.893 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
> scanned for TLDs yet contained no TLDs. Enable debug logging for this
> logger for a complete list of JARs that were scanned but no TLDs were
> found in them. Skipping unneeded JARs during scanning can improve
> startup time and JSP compilation time.
> 18-Sep-2019 09:57:43.915 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
> configuration descriptor
> /usr/local/tomcat/conf/Catalina/localhost/ROOT.xml has finished in 1,469 ms
> 18-Sep-2019 09:57:43.917 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-apr-8080"]
> 18-Sep-2019 09:57:43.925 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["ajp-apr-8009"]
> 18-Sep-2019 09:57:43.927 INFO [main]
> org.apache.catalina.startup.Catalina.start Server startup in 1528 ms
>
>
> Mikael
>
>
> On 18/09/2019 10:58, Martynas Jusevičius wrote:
> > Hi :)
> >
> > thanks for reporting, I've now fixed the links. Docker Hub reuses
> > README from GitHub, so GitHub-relative URLs don't work.
> >
> > I also added a link to the Wikidata example:
> > https://github.com/AtomGraph/Processor/tree/master/examples
> > It contains these two files:
> >
> > - wikidata.ttl is the LDT ontology of the example application. It
> > contains LDT templates, in your case :PersonItem for example.
> > The base URI (i.e. the namespace) is totally up to you, but keep in
> > mind the URI of the ldt:Ontology resource, because that is what
> > specified as -e ONTOLOGY.
> > In the Wikidata example, the ontology URI is
> > https://github.com/AtomGraph/Processor/blob/develop/examples/wikidata#
> > (with the trailing hash).
> >
> > - location-mapping.n3 - this is a config file for Jena:
> > https://jena.apache.org/documentation/notes/file-manager.html#the-locationmapper-configuration-file
> > In RDF we want to use URIs namespaces and not file paths. This file
> > provides a mapping between the two, and when an application attempts
> > to read a mapped URI, Jena actually reads it from the file it is
> > mapped to.
> > In the example,
> > https://github.com/AtomGraph/Processor/blob/develop/examples/wikidata#
> > is mapped to org/wikidata/ldt.ttl - and that is the file we mount
> > under /usr/local/tomcat/webapps/ROOT/WEB-INF/classes/ in the
> > container.
> >
> > So you do need location-mapping.n3 as well, unless your LDT ontology
> > is resolvable from its URI. In the example the ontology URI is made up
> > and there is no document behind it, so Jena would fail reading it if
> > there would be no mapping.
> >
> > I think it would be easiest for you to reuse the example as it is,
> > having copies of wikidata.ttl and location-mapping.n3 on your machine
> > (you can probably skip log4j.properties) that you mount using -v.
> > Then you can make changes in wikidata.ttl. Try to replace the
> > :BirthdaysTemplate and query with your own and see if it works. Worry
> > about namespaces and filenames later :)
> >
> > Well and -e ENDPOINT and -e GRAPH_STORE values have to be replaced
> > with your URLs of course.
> >
> > Martynas
> >
> > On Tue, Sep 17, 2019 at 3:24 PM Mikael Pesonen
> > <mikael.pesonen@lingsoft.fi> wrote:
> >>
> >> Hi again!
> >>
> >> Im reading instructions at https://hub.docker.com/r/atomgraph/processor. There are some broken links at top.
> >>
> >> docker run --rm \
> >> -p 8080:8080 \
> >> -e ENDPOINT="https://query.wikidata.org/bigdata/namespace/wdq/sparql" \
> >> -e GRAPH_STORE="https://query.wikidata.org/bigdata/namespace/wdq/service" \
> >> -e ONTOLOGY="https://github.com/AtomGraph/Processor/blob/develop/examples/wikidata#" \
> >> -v "/c/Users/namedgraph/WebRoot/Processor/src/main/resources/log4j.properties":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/log4j.properties" \
> >> -v "/c/Users/namedgraph/WebRoot/Processor/examples/wikidata.ttl":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/org/wikidata/ldt.ttl" \
> >> -v "/c/Users/namedgraph/WebRoot/Processor/examples/location-mapping.n3":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/custom-mapping.n3" \
> >> atomgraph/processor
> >>
> >> What is the puspose of wikidata.ttl and where can I find it? location_mapping.n3 can be left out if its non custom?
> >>
> >> So this would work?
> >>
> >> docker run --rm \
> >> -p 8080:8080 \
> >> -e ENDPOINT="https://query.wikidata.org/bigdata/namespace/wdq/sparql" \
> >> -e GRAPH_STORE="https://query.wikidata.org/bigdata/namespace/wdq/service" \
> >> -e ONTOLOGY="https://github.com/AtomGraph/Processor/blob/develop/examples/wikidata#" \
> >> -v "/c/Users/namedgraph/WebRoot/Processor/examples/wikidata.ttl":"/usr/local/tomcat/webapps/ROOT/WEB-INF/classes/org/wikidata/ldt.ttl" \
> >> atomgraph/processor
> >>
> >>
> >> Mikael
> >>
> >>
> >>
> >> On 17/09/2019 14:57, Martynas Jusevičius wrote:
> >>
> >> Hi Mikael,
> >>
> >> the template URI on its own is irrelevant here, it could be a blank
> >> node resource. It becomes important when one intends to reuse
> >> templates, e.g. extend them or reference them, possibly from another
> >> LDT ontology.
> >>
> >> Yes it is the ldt:match that holds the URI template that request URI
> >> is matched against. I have expanded the explanation here:
> >> https://github.com/AtomGraph/Processor/wiki/Linked-Data-Templates#templates
> >>
> >> As for the agent ID, one option to pass a value to the LDT template is
> >> using template parameters:
> >> https://github.com/AtomGraph/Processor/wiki/Linked-Data-Templates#parameters
> >>
> >> Then if a request URI is
> >> https://resource.lingsoft.fi/286c384d-cd5c-4887-9b85-94c0c147f709?agent=123456,
> >> a variable binding (?agent, "123456") is applied to the query string
> >> from ldt:query, before it is executed.
> >> This might or might not work for your use case.
> >>
> >> Martynas
> >>
> >> On Tue, Sep 17, 2019 at 1:43 PM Mikael Pesonen
> >> <mikael.pesonen@lingsoft.fi> wrote:
> >>
> >> Hmm, still mixing up things. So ldt:match has to match the resource URI.
> >>
> >> On 17/09/2019 12:13, Mikael Pesonen wrote:
> >>
> >> Ok now I got it, the template address has to be the same as resource URI.
> >> Just one question, in our case, https://base/{uuid}, how should we
> >> forward the agent id (access level) to the template for utilizing ACL?
> >>
> >>
> >>
> >> On 17/09/2019 11:40, Martynas Jusevičius wrote:
> >>
> >> Thanks Mikael,
> >>
> >> the example makes it clearer.
> >>
> >> So the URI template for all persons (and I guess all resources in
> >> general?) is "/{uuid}", if we take https://resource.lingsoft.fi as the
> >> base URI. Which means that you could not match two different LDT
> >> templates for different types of persons.
> >>
> >> Then my suggestion with using a single template with a query that
> >> references the ACL graph still stands. Let me know if you need help
> >> setting it up in Processor.
> >>
> >> Martynas
> >>
> >> On Mon, Sep 16, 2019 at 11:27 AM Mikael Pesonen
> >> <mikael.pesonen@lingsoft.fi> wrote:
> >>
> >> 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
> >>
> >> --
> >> 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 Wednesday, 18 September 2019 10:20:50 UTC