- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 9 Jul 2014 18:07:34 +0200
- To: <public-hydra@w3.org>
- Cc: <public-linked-json@w3.org>
On 9 Jul 2014 at 10:49, Tomasz Pluskiewicz wrote: > On Wed, Jul 9, 2014 at 12:11 AM, Markus Lanthaler wrote: >> On 8 Jul 2014 at 23:16, Tomasz Pluskiewicz wrote: >>> On Stackoverflow [1] Dave gave me some advice about how a client would >>> either expand or use a well-known context to compact a resource >>> representation to inspect its contents. >>> >>> I intend to implement a Hydra client, >> >> That's great! >> >> >>> which would allow passing a well-known context. >> >> What do you mean by this? Do you mean a client which can be >> "configured" by passing it a context? > > I mean that the end client (as opposed to the Hydra client) can > request a resource compacted in a specific context. You mean the application controlling/driving the Hydra client requests a compacted resource, right? Makes sense. >>> Now I'm wondering what is your suggested algorithm to process the >>> resource to discover hydra:Links and hydra:Operations. >> >> It depends on what exactly you are trying to achieve. The Hydra >> console [2] does everything by just using JSON-LD that is framed by >> a proxy [3]. An alternative would be to convert everything to >> triples and put it in a triple store (client side) that can be >> queried to get the hydra:Links/Operations of interest. > > I want to create the Hydra client to retrieve a resource and discover > all links and operations by looking at the representation and by > inspecting hydra:Classes and hydra:Links. Thus types and properties > would also have to be dereferenced. Yeah, to really get every possible operation and link, you would need to reference all of them. I'm still a bit on the fence about that because it is extremely inefficient in most cases. I was thinking about adding a statement to the spec that basically requires all links and operations to be declared either in the ApiDocumentation or inline so that there are only those two places for a client to look at. Of course people can place information also directly in vocabularies but then it wouldn't be guaranteed that those things are discovered *unless* they are also referenced by a apiDocumentation HTTP Link header. > My current approach is that the resource object will expose additional > functions, which will process the representation. So the usage would > something like below. > > var resource = hydra.$get('/some/resource', context /* optional */ ); > > var links = hydra.$links(); links['http://some/link/propety'].$get(); > > var operations = resource.$operations(); > operations['http://some/OperationType'].$invoke() Do not forget that a representation can contain information about multiple resources. Think of the representation of a collection. There's not only the collection itself but also a number of members of that collection and each of them can support various links/operations. > I expect the $get() and $invoke() methods on links and operations to > allow optional parameters such as template params or operation body. > > Does this make sense? Yep. There *probably* also needs to be a way to find out what parameters are available. >>> 1.Would you keep an expanded/flattened document for processing and a >>> compacted to return to the client? >> >> Keep it where? >> > > Keep in memory during representation processing. For example, the end > client requests a resource representing a person: > > <AnakinSkywalker> a ex:Person; ex:knownAs "Darth Vader"; ex:child > <LukeSkywalker> . > > The end client may want that resource as JSON-LD in a custom context > > { "alias": "ex:knownAs", "offspring": "ex:child" } > > So the expected document should be > > { > "@context": { "alias": "ex:knownAs", "offspring": "ex:child" }, > "@id": "AnakinSkywalker", > "@type": "ex:Person", > "alias": "Darth Vader", > "offspring": <LukeSkywalker> > } > > And at the same time I would like to extract information about links > and operations and serve it > > 1. compact first and discover links and operation by processing the > result Since the context is supplied by the application and not defined by the client library itself, this is probably the most difficult thing to implement. > 2. expand, discover links/operations and compact in the end I would separate them. Instead of expanding I would flatten or frame the response to discover links and operations and separately compact (frame?) the response for the application using the client library. > 3. convert to triples, discover links/operations from those triples and > compact whenver, because these two processes are not interdependent > > Or maybe another approach would be better? > > I kind of like the idea of processing triples, because it spearates > concerns. Though I expect it will be more difficult with external > resources, ie. types and properties that need to be dereferenced and > inspected. Unless there is a SPARQL processor in JS, which allows > fetching remote URIs from GRAPH patterns. There's no difference regarding external resources IMO. -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 9 July 2014 16:08:08 UTC