- From: Daniel Smedegaard Buus <danielbuus@gmail.com>
- Date: Tue, 23 May 2017 08:02:48 +0200
- To: james anderson <james@dydra.com>
- Cc: Linked JSON <public-linked-json@w3.org>
Okay, you guys are using a lot of slightly confusing terminology :D What I don't like about the Hydra approach is that it encapsulates my type with its own "Collection" type, so instead of having, say, a property "users" which is of @type "mycontext:User", it is now the generic hydra:Collection @type, which then can contain a "hydra:member" property where each item in it has to declare their actual type of "mycontext:User". Not only does it obfuscate the context from expressing exactly what type a property will contain, it also loosens the contract to the consumer, allowing me as a producer to throw anything in there (the generic hydra:Collection). At least AFAICT, but as I said, I'm two weeks in ;) I'd much rather be able to "augment" a graph with a couple of extra meta properties which would contain this pagination data. But as I understand it, any context "extras" that go into a @graph node apply to items in the graph, not to the graph... When I started out two weeks back, I also briefly considered the Range header, but there are a couple of reasons why I don't want to go that route: 1) The Range header has a completely different meaning 2) I have much more information that I want to convey and consume, such as number of pages, links to pages, sorting, etc., and they don't fit in there either. 3) HTTP headers are, well, HTTP-gnostic. I'd like my API to be transport-agnostic. And apart from that, putting pagination information in a header transfers state from the document to the transport layer, and I really want the API to offer REST in and of itself, and in all possible transport scenarios, be it HTTP, RPC, Unix sockets or carrier pigeons :D. Am I correct in assuming that as of the current JSON-LD specification goes, I cannot "augment" something like a @graph to "put extra stuff in there, like pagination metadata" without having to put it onto items in the graph? I'll have another look at the ActivityStream concept, but it's not so much *how* I should paginate data as much as it is how I can avoid any approach "messing" with my contexts. I realize that JSON-LD is more about linking data than it is about schemafying your data, but the schema part of JSON-LD is fantastic IMHO. I love that right now, I can tell our outhouse iOS developers to pull the contexts, and it's immediately apparent what they can expect to get. User.comments is of type mycontext:Comment. Easy. If anyone sees any way that I can keep my contexts as accurate as they are now, but be able to add pagination metadata to a document, I'd love the input :) (For one, I'd love to see an example of how those ActivityStream concept have been incorporated into a JSON-LD document!) Thanks again, all, for all your thoughts! Daniel
Received on Tuesday, 23 May 2017 06:04:05 UTC