Re: [apps-discuss] NEW RELATION: property and context

["Markus Lanthaler" <[e-mail]>]

On Wednesday, May 29, 2013 9:35 AM, Ioseb Dzmanashvili wrote:
> Here is the example:
> 
> *** REQUEST: Fetch photo ***
> > GET /article/photo HTTP/1.1
> > Host: service.org
> 
> *** RESPONSE: Photo representation ***
> < HTTP/1.1 200 OK
> < Content-Type: image/jpeg
> < Content-Length: ...
> < Link: </article/photo;prop1>; rel="property"; title="Property 1",
> <   </article/photo;prop2>; rel="property"; title="Property 2",
> <   </article/photo>; rel="self"; title="...",
> <   </article>; rel="context" title="Thousand Leagues Under the Sea"
> <   
> < [BINARY DATA HERE]
> 
> *** REQUEST: Fetch one of the properties ***
> > GET /article/photo;prop1
> > Host: service.org

This is right at the heart of my first question: How does the client know to fetch /article/photo;prop1 instead of /article/photo;prop2?

There are only two options here: a) code against the target URL or b) code against the title attribute. Since you said b) is used exclusively for rendering purposes I assume you would code your client against the URL (or parts thereof) which would go against the fundamental idea of typed links.


> *** RESPONSE: property representation ***
> < HTTP/1.1 200 OK
> < Content-Type: text/plain
> < Link: </article/photo;prop1>; rel="self" title="...",
> <   </article/photo>; rel="context"; title="..."
> < 
> < [PROPERTY VALUE HERE]
> 
> Based on this example, i'm not sure how the "describes" link relation
> can be used instead of the "context" link relation when by definition
> the "describes" relations says that: "The relationship A 'describes' B
> asserts that resource A provides a description of resource B. There
> are no constraints on the format or representation of either A or B,
> neither are there any further constraints on either resource."? In
> this particular example "context" indicates resource to which the
> /article/photo or /article/photo;prop1 resources belong and  context
> resources do not provide any description of those members.

Hmm.. I do partly agree for the /article/photo -> /article link but would argue that /article/photo;prop1 does *describe* /article/photo. Similarly it could be argued that /article/photo *isDescribedBy* /article.


> What i
> want to say here it's a simple relationship between two resources
> without any descriptions etc…

So you want to express a relationship without any specific semantics? In that case, why do you need a typed link? Can't you just use a untyped one?


> Same with the "collection" and "item" relationships, i do not see(or
> maybe do not understand?) how /article and /article/photo resources
> are collections?

If article would be called slideshow or gallery, would you see it then? :-) You could say that an article is a collection of information, some prose, some images, maybe some movies etc.


> if yes, collections of what? generally we can say
> that everything is an item but taking the definition of the "item"
> link relation: "The target IRI points to a resource that is a member
> of the collection represented by the context IRI." Now if we consider
> following example:
> 
> < HTTP/1.1 200 OK
> < Content-Type: …
> < Content-Length: …
> < Link: </article>; rel="self"; title="…",
> <    </article/photo>; rel="enclosure" title="…"
> <
> < [REST OF CONTENT HERE]
> 
> can we say for /article/photo resource that context IRI represents a
> collection? or does the /article resource somehow "describes" the
> /article/photo resource? or is /article/photo resource is an item
> which belongs to collection?

Could be any of those. If the article describe the photo you could use "describes". If the article is more a collection of information (e.g. pictures as in a gallery) you could say it is a "collection" and the photo is an "item".


Btw. On mailing lists it is typically considered as a best practice to write text-only mails. This makes it much easier to quote etc. Could you please update your client settings to send text-only mails instead of HTML formatted mails. Thanks a lot!



--
Markus Lanthaler
@markuslanthaler