- From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Date: Fri, 27 Nov 2015 17:27:01 +0100
- To: public-hydra@w3.org
Hi, On 11/27/2015 05:04 PM, Lukas Graf wrote: > GET/buildings/main/ - retrieves the collection members of the "main" building > GET /buildings/main/lobby - retrieves the "lobby" room > (POST/buildings/main/ - create a new "Room" resource in the "main" building) > > we wouldn't have a way to access the collection's metadata (the building's "address" for example). So for that reason it seems we do need some intermediate level between the container and the contentish resource. No one prevents you from using the "other dimensions" of an IRI such as the query string to differentiate here. For example to interact with the meta data part of a resource, you can just have a ?meta in the URL. That's still restful as a different IRI can point to a completely different resource, even if the difference is only in the query string. ... > Yes, just usinghttp://example.org as the IRI for our domain specific context was a simplification for the sake of brevity. In reality, there will probably one context per content type, and it would maybe be referenced ashttp://example.org/contexts/Building.jsonld. But then many content types also include some standard DublinCore metadata, so that would be a separate context, possibly even hosted externally. > > But as for namespacing of properties / terms, I think with @vocab and local contexts we have all the tools required to manage that. I have exactly the same design. Currently one context per type. But what you could do is to just have multiple types and contexts which is possible with JSON-LD. That way you could factor out commons. BG, Thomas
Received on Friday, 27 November 2015 16:27:44 UTC