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

[Ioseb Dzmanashvili <[e-mail]>]

On Wednesday, May 29, 2013 at 10:39 PM, Markus Lanthaler wrote:
> 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 (http://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 (http://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.
Both options are wrong.  

> a) code against the target URL or

1) the "property" link relation is enough to indicate that target resource is a property and allow agents to distinguish these links form others;  
2) additional semantics can be provided with extension link relations and there is nothing wrong with it, it doesn't violate anything nor can be considered as anti pattern.
3) your argument implicitly claims that there exists only M2M interaction which is also wrong. there are also GUI apps for which it's enough to just know that some of links are properties(identified by the "property" relation)
4) having a general purpose link relation makes it useful and reusable from application to application, it eliminates need to redefine each time what "property" is and is media format agnostic. shared understanding is important i believe and additional semantics for each specific property is solvable on another level.

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

very strange assumption.  
  
> > *** 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.
Are you sure that "describedby" and "describes" relations give enough semantics to agents? is not it necessary to provide  some kind of description? if one describes another how it is described?  and what it gives to agent particularly in M2M interaction case? do automated agents strangely become smart and happy when they just identify typed links annotated with those relations?
> > 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?
Than how GUI or automated agent will distinguish resources which are properties accessible individually from for example the "edit" or "edit-form" links? or implementations are going to follow some convention like: if a link doesn't have relation just display it? or ignore 'em? or?
> > 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.
but i didn't say "gallery" or "slideshow" in my example. what if a resource is an ID card which has only one and only one photo of a person? do you think that ID card or driving license are collections? and yes i can not say that an article is a collection, not because we can not say it generally but because what you say is overgeneralisation of things. we can discuss everything as a collection and item but what you say makes me think that "collection", "item", "describes" and "describedby" link relations suddenly solved whole world problems.
> > 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".
could you please point me to the example how article describes photo? it would be really helpful for me!.  I believe i know and clearly understand when i can say that an article is a collection, but does it make whole world a collection? again, is not it overgeneralisation and oversimplification of things?  
>  
>  
> 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!
done, thanks for letting me know.  
>  
> --
> Markus Lanthaler
> @markuslanthaler

cheers,  
ioseb