From ioseb.dzmanashvili@gmail.com  Sun Jun  2 12:11:03 2013
Return-Path: <ioseb.dzmanashvili@gmail.com>
X-Original-To: link-relations@ietfa.amsl.com
Delivered-To: link-relations@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038B21F91CA; Sun,  2 Jun 2013 12:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_91=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxq0eC0C8-wb; Sun,  2 Jun 2013 12:11:02 -0700 (PDT)
Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B743D21F91BF; Sun,  2 Jun 2013 12:11:01 -0700 (PDT)
Received: by mail-ea0-f170.google.com with SMTP id h10so616513eaj.1 for <multiple recipients>; Sun, 02 Jun 2013 12:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=P1pcUbp2OEJYtxd8/oj3OfbRqFsp9XcftzJlAFRJ+nc=; b=bZcLH2W6FyLgrHrepvObZAJRGINGd9Cr8LhuHZu5XjBWzC4aQo4FDbEU0w1Lgiplqd kIeubYcR5Kc02MOBFApu0ZBlbhUDkJgSzpFUsUO5LMf5NNFJE4c+kgU8QKTzGV0M5BDe 9u2mG7lOEB13aDSRoPzG+JhyqwlifzPbs/itObw0+2vKk5QZFB1SBWXzx6uC0s0pIfwv nduFCl1XCa1p6eACzqJBZplu/a9dQlx7XvRk9xgvzyCLUFOcL8/15Y00qw4Q3P0vYj2M cevaah+Vj1SoxQ/C+k0ctB6Xom7XvSbrwjUZT4K6nLd7Wi5IXlOQYabi/3oHRLYLvdcW i3rw==
X-Received: by 10.15.90.139 with SMTP id q11mr6680929eez.137.1370200260833; Sun, 02 Jun 2013 12:11:00 -0700 (PDT)
Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id bo9sm66067589eeb.9.2013.06.02.12.10.58 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 02 Jun 2013 12:10:59 -0700 (PDT)
Date: Sun, 2 Jun 2013 23:10:55 +0400
From: Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Message-ID: <3090B4B6BA1F427BB7433814C140CAAD@gmail.com>
In-Reply-To: <51a932b9.c8490f0a.4879.ffff86b3SMTPIN_ADDED_BROKEN@mx.google.com>
References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <CABP7Rbd815stpCPLL5q9eVuxbHDW6NbGrBPdfjJbSywKFRRJ4g@mail.gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbfbicAaXOpy8r3w-YVmLjM=APLDjhTohUgGnqAfkHm0dA@mail.gmail.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> <FEB564CAAF9B47B8BE41F0BBE8556650@gmail.com> <51a64b5f.87000e0a.78ef.ffff87a2SMTPIN_ADDED_BROKEN@mx.google.com> <87194C5A218E42F9AA9B81339D2C1BC5@gmail.com> <51a932b9.c8490f0a.4879.ffff86b3SMTPIN_ADDED_BROKEN@mx.google.com>
Subject: Re: [apps-discuss] NEW RELATION: property and context
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, link-relations@ietf.org
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jun 2013 19:11:03 -0000

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 clien=
t
> > =20
> > =20
> > know to fetch /article/photo;prop1 instead of /article/photo;prop2=3F=

> > > =20
> > > 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 exclusi=
vely
> > > 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.
> > =20
> > =20
> > =20
> > Both options are wrong.
> > =20
> > > a) code against the target URL or
> > =20
> > 1) the =22property=22 link relation is enough to indicate that target=

> > resource is a property and allow agents to distinguish these links fo=
rm
> > others;
> =20
> =20
> =20
> Yes, distinguish from other rels, but not enough to distinguish two pro=
perties as in your example:
> =20
> *** RESPONSE: Photo representation ***
> HTTP/1.1 200 OK
> Content-Type: image/jpeg
> Content-Length: ...
> Link: </article/photo;prop1>; rel=3D=22property=22; title=3D=22Property=
 1=22,
> </article/photo;prop2>; rel=3D=22property=22; title=3D=22Property 2=22,=

> =20
As I already mentioned in my previous emails, annotated links are very im=
portant in apps designed for humans too.  =20
> =20
> > 2) additional semantics can be provided with extension link relations=

> > and there is nothing wrong with it, it doesn't violate anything nor c=
an
> > be considered as anti pattern.
> =20
> =20
> Right, but the question I ask myself then is why you need the generic =22=
property=22 relation then.
=46or several reasons:

1) we do not need to redefine meaning of the =22property=22 relation from=
 application to application
2) we do not need to define meaning of the property from media type to me=
dia type
3) shared understanding of what the =22property=22 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 a=
pplication specific. =20
> > 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 t=
he
> > =22property=22 relation)
> =20
> =20
> =20
> Hmm... it helps you to render just the property links, yes. But then th=
e 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 labe=
l, this is what they understand but yet application logic needs at least =
basic understanding of what the link means. =20
> > 4) having a general purpose link relation makes it useful and reusabl=
e
> > from application to application, it eliminates need to redefine each
> > time what =22property=22 is and is media format agnostic. shared
> > understanding is important i believe and additional semantics for eac=
h
> > specific property is solvable on another level.
> =20
> =20
> =20
> 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:
> =20
> Link: </a/resource>; rel=3D=22link=22
> =20
> This allows your application to render all =22link=22 links but by itse=
lf doesn't add any semantics beyond the ones the Link header already has.=

> =20
yes it sound reasonable, but this is a different story, the =22property=22=
 relation doesn't mean =22render it=22 it defines specific kind of relati=
onship between resources stating that this one is a property of that one(=
or vice versa) and it doesn't mean =22here is the link and grab it and re=
nder it=22 =20
> =20
> =20
> =5B...=5D
> > > Hmm.. I do partly agree for the /article/photo -> /article link but=

> > > would argue that /article/photo;prop1 does *describe* /article/phot=
o.
> > > Similarly it could be argued that /article/photo *isDescribedBy*
> > > /article.
> > =20
> > =20
> > =20
> > Are you sure that =22describedby=22 and =22describes=22 relations giv=
e enough
> > semantics to agents=3F is not it necessary to provide some kind of
> > description=3F
> =20
> =20
> =20
> Yes, this alongside the media type of the referenced/referencing resour=
ce provides enough semantics for an agent to do something useful with it.=

Does this approach work well with =22image/jpeg=22 or =22image/png=22 or =
=22application/zip=22 media types=3F Or is it always reasonable to wrap t=
hese binary media types in another media types which describe binary reso=
urce and its properties=3F how it works with HEAD requests=3F
> > if one describes another how it is described=3F
> =20
> =20
> The media type defines that. One obvious answer is e.g. RD=46.
> =20
See my answer above. =20
> =20
> =20
> > and what it
> > gives to agent particularly in M2M interaction case=3F do automated
> > agents strangely become smart and happy when they just identify typed=

> > links annotated with those relations=3F
> =20
> =20
> =20
> 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 p=
roperties/contexts but that would mean that you, e.g., would have to defi=
ne media types for all properties so that clients can express what they u=
nderstand. 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.
> =20

mmm=E2=80=A6 and who says that dereferencing the property link couldn't h=
ave information describing the property itself and still maintaining the =
=22property=22 type relationship between resources=3F
> =20
> > > So you want to express a relationship without any specific semantic=
s=3F
> > > In that case, why do you need a typed link=3F Can't you just use a
> > > untyped one=3F
> > =20
> > =20
> > =20
> > Than how GUI or automated agent will distinguish resources which are
> > properties accessible individually from for example the =22edit=22 or=

> > =22edit-form=22 links=3F or implementations are going to follow some
> > convention like: if a link doesn't have relation just display it=3F o=
r
> > ignore 'em=3F or=3F
> =20
> =20
> =20
> Displaying just links without relation would be a reasonable design cho=
ice IMO because they do not provide enough semantics to be handled automa=
tically. Thus, the choice has to be made by the (human) user which interp=
rets the link's label, i.e., the title attribute.
> =20
So would be ignoring 'em. Why should agents care about links without rela=
tions(i do not mean HTML where this kind of approach works perfectly)=3F =
=20
> =20
> =20
> > > If article would be called slideshow or gallery, would you see it
> > > then=3F :-) You could say that an article is a collection of
> > > information, some prose, some images, maybe some movies etc.
> > =20
> > =20
> > =20
> > but i didn't say =22gallery=22 or =22slideshow=22 in my example. what=
 if a
> > resource is an ID card which has only one and only one photo of a
> > person=3F do you think that ID card or driving license are collection=
s=3F
> =20
> =20
> =20
> =46irst of all, I don't understand why such a link would have to be exp=
osed 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 probabl=
y don't even have to invent it yourself as other people did already and y=
ou profit in terms of interoperability and code reusability if you just r=
euse it. The =46OA=46 Vocabulary e.g., defines a =22depiction=22 URL whic=
h you could use. See:
> http://xmlns.com/foaf/spec/=23term=5Fdepiction
> =20

I understand your point, but it constrains me(my applications - clients a=
nd servers) to RD=46/=46OA=46 things which is not acceptable always(due t=
o different requirements). =20
> =20
> > 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 overgeneralisati=
on
> > of things. we can discuss everything as a collection and item but wha=
t
> > you say makes me think that =22collection=22, =22item=22, =22describe=
s=22 and
> > =22describedby=22 link relations suddenly solved whole world problems=
.
> =20
> =20
> =20
> :-) You are putting words in my mouth. I tried to show that that =22pro=
perty=22 has extremely weak semantics - IMHO too weak.
> =20
Not that weak IMHO :-) =20
> =20
> =20
> =5B...=5D
> > > Could be any of those. If the article describe the photo you could
> > > use =22describes=22. If the article is more a collection of informa=
tion
> > > (e.g. pictures as in a gallery) you could say it is a =22collection=
=22 and
> > > the photo is an =22item=22.
> > =20
> > =20
> > =20
> > could you please point me to the example how article describes photo=3F=

> > it would be really helpful for me=21
> =20
> =20
> =20
> http://en.wikipedia.org/wiki/Vitruvian=5FMan *describes* http://upload.=
wikimedia.org/wikipedia/commons/2/22/Da=5FVinci=5FVitruve=5FLuc=5FViatour=
.jpg
> =20

Thanks=21
> =20
> > I believe i know and clearly
> > understand when i can say that an article is a collection, but does i=
t
> > make whole world a collection=3F again, is not it overgeneralisation =
and
> > oversimplification of things=3F
> =20
> =20
> =20
> No, of course not. But every link is a property of a resource and thus,=
 again IMO, =22property=22 has too weak semantics for a standardized link=
 relation.
> =20

I do not agree. One thing is that i didn't give enough description in dra=
ft and i understand confusion, second thing is that i submitted it and st=
arted discussion in hope to re-shape it's purpose more precisely. With th=
is relation i'm trying to define relationship between a property(which is=
 an individually accessible data member) and it's defining context. I'm n=
ot trying to define and convince everyone that everything is just a prope=
rty. =20
> =20
> > > 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. C=
ould
> > > you please update your client settings to send text-only mails inst=
ead
> > > of HTML formatted mails. Thanks a lot=21
> > =20
> > =20
> > =20
> > done, thanks for letting me know.
> =20
> Thanks a lot=21 This definitely makes replying much easier
> =20

np ;-) =20
> =20
> =20
> --
> Markus Lanthaler
> =40markuslanthaler


Cheers,
ioseb =20