Re: Inheritance / composition of term definitions

Hi Karel,

On 11/27/2015 08:53 PM, Karol Szczepański wrote:
> Hi
>>> 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.

>
> 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.

BG

[1] http://www.w3.org/TR/ldp/#link-relation-describedby