Re: Inheritance / composition of term definitions

On 27 Nov 2015, at 17:27, Thomas Hoppe <thomas.hoppe@n-fuse.de> wrote:

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

Sure, that would work. But I feel that this would be a bit cumbersome to use. This case (accessing a folderish object's properties) is frequent enough that it would probably feel strange to users of the API that are familiar with the CMS. And to be consistent, the properties of a non-folderish object then would also have to be accessed using ?meta, which is definitely not viable.

Maybe my use of the term "metadata" was a bit misleading. It's really just properties / attributes of the object. Those consist of primary data attributes as well as some data *about* the object (some DublinCore metadata for example). Our CMS doesn't really distinguish between those. But in the case of folderish objects, the "main" content you're usually interested in are its immediate children. The non-DC properties of folderish objects are usually very limited, maybe an id and a title. But they're important nonetheless, and should be accessed the same way as properties for non-folderish objects.

Lukas

Received on Tuesday, 1 December 2015 00:13:50 UTC