Re: Inheritance / composition of term definitions

Hi Thomas

>>>>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. 
>>I'd disagree - it needs a client to know something extra. 
>>I'd go with something that's a common ground for both client and server - HTTP feature. 
>>Meaybe a verb (i.e. OPTIONS - only drawback is that responses are not cacheable), a specific acceptable content type or a request Link header with some specific rel, i.e. >>meta. 
>>I think an extra query string parameter is far from what ReST presents. 
>>Optionally, you could indeed have that query string parameter, but this should be additionally described with some hypermedia controls achieveing both ReST and HATOAS >>simultanously. 
>Maybe I should have added that of course you would then need to provide a link to this meta data part embedded in the resource described by the meta data.
>This is straight forward, you coin a new predicate in the vocabulary of my domain or use something more generic like 
>the 'described by' link relation [1].
>Either way there is no implicit knowledge required by the client and I see no way in this wouldn't be restful.
Yes, you can do all of that. Some “domain specific” vocabulary can point that kind of info. Not very generic, but doable.
Also it forces client to understand more and more vocabularies making it complicated.

>>In general, we've touched a matter of having data and meta-data/hypermedia controls mixed in several discussions now.
>>I personally prefer to push that out of the data i.e. to headers or separate request or separate RDF graph. I believe Hydra spec is silent in this area. 
>Personally I don't like headers. 
>In my case this approach would fail only due to the amount of meta data.
I’m not as well, but for some scenarios headers may prove very powerful. When POSTing a resource to be created a header points to a newly created resource’s Url – clean and effective.

Best

Karol