Simon,

with LDT, every application is a service, backed by SPARQL dataset,
and driven by an ontology.

The service description is made discoverable by making the ontology
dereferencable. Every LDT response contains header information linking
the resource back to the application, to its ontology, and the
matching template.

LDT generates SPARQL commands from templates. They are part of the
service description, therefore also part of the ontology. SPIN RDF
vocabulary makes it easy to embed SPARQL in RDF form.

There is currently no registry of LDT apps/services, although it
wouldn't be hard to implement (as an LDT app :))
We are currently working on a cloud platform that will offer hosted
apps with a user-friendly UI. In principle it could interact with
hosted as well as registered 3rd party LDT apps. So far we haven't had
this use case though.

On Tue, Aug 23, 2016 at 11:51 PM, Simon Schäfer <m...@antoras.de> wrote:
>
>
>
> ---- On Sun, 21 Aug 2016 23:31:30 +0200 Martynas Jusevičius 
> <marty...@graphity.org>wrote ----
>
>  > Simon,
>  >
>  > I think Linked Data Templates could be something that you are looking for:
>  > 
> https://github.com/AtomGraph/Linked-Data-Templates/tree/master/XML%20London%202016%20paper
>  >
>  > The paper does not go into such detail, but we use SPIN templates as
>  > SPARQL functions with arguments set from request query string. This is
>  > an API description as OWL ontology, with Linked Data Templates and
>  > SPIN templates:
>  > 
> https://github.com/AtomGraph/Processor/blob/master/src/main/resources/org/graphity/processor/gp.ttl
>  >
>  > Besides Processor, there is also Web-Client -- they communicate using
>  > hypermedia generated from template calls. Let me know if you need more
>  > info, and join our Community Group :)
>  > https://www.w3.org/community/declarative-apps/
>
> This looks indeed very interesting even though I'm not yet able to understand 
> all of the ideas behind LDT. The paper didn't describe anything about service 
> interaction (registering, deregistering, finding and calling them). Is this 
> something you have been working on too and if yes could you give an example 
> of how it could look like?
>
> In general I don't understand yet what the advantage is to generate SPARQL 
> updates from turtle files. In the paper there is an example given in 5.1.1 
> but why would one not write the SPARQL query directly?
>
> The Processor, does it already provide possibilities (APIs) to interact with 
> services? Would you suggest to use it already as a dependency or am I better 
> advised to just understand LDT and implement its standard roughly in order to 
> benefit from its ideas?
>

Reply via email to