- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Fri, 30 Jun 2017 19:16:53 +0200
- To: Alfredo Serafini <seralf@gmail.com>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, "Gray, Alasdair J G" <A.J.G.Gray@hw.ac.uk>, public-lod <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>, Hydra <public-hydra@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
- Message-ID: <CAE35VmzC13k3vcBAxXbQUqPt4ZF+OK0MiNmQXnJe2jOae=ZsQA@mail.gmail.com>
Kingsley, Alfredo, I could mention many reasons why we haven't reused Swagger or a different API description format: 1) it's not RDF 2) it's not an ontology 3) no standard way to embed SPARQL 4) depends explicity on HTTP etc. Most importantly, Swagger is only a description, while LDT not only provides a description, but also a method to evaluate that description in order to produce a response [1]. So LDT ontology is more like a definition of an API, rather than a description. I'm not aware of any other spec that provides this kind of evaluation. You could compare it to SPARQL algebra [2]. It's not that we decided one day that the world needs one more API description format. No, LDT has evolved over many years of building SPARQL- and Linked Data-native systems. Since it's useful to us, we think that by extension it could be useful for other people working on such software. [1] https://atomgraph.github.io/Linked-Data-Templates/#http-valuation [2] https://www.w3.org/TR/sparql11-query/#sparqlAlgebra On Fri, Jun 30, 2017 at 6:54 PM, Alfredo Serafini <seralf@gmail.com> wrote: > Hi Kingsely and all > > I agree with this: > > >> Have you considered using OpenAPI (nee Swagger) to document your APIs? >> Doing that would provide another point of intersection between "Web >> Developers" and "Semantic Web Developers" . >> >> >> [1] https://medium.com/openlink-software-blog/swagger-the-api-ec >> onomy-rest-linked-data-and-a-semantic-web-9d6839dae65a -- Swagger, the >> API Economy, REST, Linked Data, and a Semantic Web >> >> > moreover I would guess that approaching to API design as a collaborative > effort (even before providing the actual underling implementation) could be > a way to deepen the discussion. > The community could be interested in merging approaches and best > practices, as Kingsley said, avoiding choices that could be problematic on > one of the side (for example opaque URI,, and so on...). > Given the current status of stadards, with LDP, LDF, it would be useful to > underline in a practical manner the benifits of a "new" standard around > resources. For example for some reason I imagine some similarities with the > ideas behind the "old" Fresnel approach in some way (at least when > reading/navigating a resource) here (am I completely wrong?), but maybe I > didn't understand at all the context :-) Engaging people around playable > wip examples could be a way to focus on the crucial parts. > > > my > > >
Received on Friday, 30 June 2017 17:17:27 UTC