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

[Ioseb Dzmanashvili <[e-mail]>]

On Saturday, June 1, 2013 at 3:30 AM, Markus Lanthaler wrote:
> 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",
>  
As I already mentioned in my previous emails, annotated links are very important in apps designed for humans too.   
>  
> > 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.
For several reasons:

1) we do not need to redefine meaning of the "property" relation from application to application
2) we do not need to define meaning of the property from media type to media type
3) shared understanding of what the "property" relationship is, takes away needles part of redefining it each time we need it and we only need to concentrate on describing particular properties which obviously are application specific.  
> > 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.
In non m2m interaction yes users choose the right links based on the label, this is what they understand but yet application logic needs at least basic understanding of what the link means.  
> > 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.
>  
yes it sound reasonable, but this is a different story, the "property" relation doesn't mean "render it" it defines specific kind of relationship between resources stating that this one is a property of that one(or vice versa) and it doesn't mean "here is the link and grab it and render it"  
>  
>  
> [...]
> > > 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.
Does this approach work well with "image/jpeg" or "image/png" or "application/zip" media types? Or is it always reasonable to wrap these binary media types in another media types which describe binary resource and its properties? how it works with HEAD requests?
> > if one describes another how it is described?
>  
>  
> The media type defines that. One obvious answer is e.g. RDF.
>  
See my answer above.  
>  
>  
> > 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.
>  

mmm… and who says that dereferencing the property link couldn't have information describing the property itself and still maintaining the "property" type relationship between resources?
>  
> > > 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.
>  
So would be ignoring 'em. Why should agents care about links without relations(i do not mean HTML where this kind of approach works perfectly)?  
>  
>  
> > > 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
>  

I understand your point, but it constrains me(my applications - clients and servers) to RDF/FOAF things which is not acceptable always(due to different requirements).  
>  
> > 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.
>  
Not that weak IMHO :-)  
>  
>  
> [...]
> > > 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
>  

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

I do not agree. One thing is that i didn't give enough description in draft and i understand confusion, second thing is that i submitted it and started discussion in hope to re-shape it's purpose more precisely. With this relation i'm trying to define relationship between a property(which is an individually accessible data member) and it's defining context. I'm not trying to define and convince everyone that everything is just a property.  
>  
> > > 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
>  

np ;-)  
>  
>  
> --
> Markus Lanthaler
> @markuslanthaler


Cheers,
ioseb