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

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

On Wednesday, May 29, 2013 10:08 PM, Ioseb Dzmanashvili wrote:
> > 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;

Yes, distinguish from other rels, but not enough to distinguish two properties as in your example:

*** 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",


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

Right, but the question I ask myself then is why you need the generic "property" relation then.


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

Hmm... it helps you to render just the property links, yes. But then the user has to choose the right link based on the title attribute.


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

Right, but property is so generic that I have problems seeing its value. This goes a bit in the direction of Jan's question. Would you think the following would be a reasonable design choice:

   Link: </a/resource>; rel="link"

This allows your application to render all "link" links but by itself doesn't add any semantics beyond the ones the Link header already has.


[...]
> > 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?

Yes, this alongside the media type of the referenced/referencing resource provides enough semantics for an agent to do something useful with it.


> if one describes another how it is described?

The media type defines that. One obvious answer is e.g. RDF.


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

No, but they do know that they can follow the link to get a description which they (may) understand. You could argue that the same is true for properties/contexts but that would mean that you, e.g., would have to define media types for all properties so that clients can express what they understand. Just returning a string as text/plain for a title property is definitely not enough to enable M2M communication without having to rely on out-of-band information.


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

Displaying just links without relation would be a reasonable design choice IMO because they do not provide enough semantics to be handled automatically. Thus, the choice has to be made by the (human) user which interprets the link's label, i.e., the title attribute.


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

First of all, I don't understand why such a link would have to be exposed on the HTTP layer. If you really want to, I think in such a specific case it makes much more sense to use a URL as link relation. You probably don't even have to invent it yourself as other people did already and you profit in terms of interoperability and code reusability if you just reuse it. The FOAF Vocabulary e.g., defines a "depiction" URL which you could use. See:
http://xmlns.com/foaf/spec/#term_depiction


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

:-) You are putting words in my mouth. I tried to show that that "property" has extremely weak semantics - IMHO too weak.


[...]
> > 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!

http://en.wikipedia.org/wiki/Vitruvian_Man *describes* http://upload.wikimedia.org/wikipedia/commons/2/22/Da_Vinci_Vitruve_Luc_Viatour.jpg


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

No, of course not. But every link is a property of a resource and thus, again IMO, "property" has too weak semantics for a standardized link relation.


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

Thanks a lot! This definitely makes replying much easier



--
Markus Lanthaler
@markuslanthaler