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

Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com> Wed, 29 May 2013 07:35 UTC

Return-Path: <ioseb.dzmanashvili@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE48421F8EC2 for <apps-discuss@ietfa.amsl.com>; Wed, 29 May 2013 00:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 i6Iu4sa5HbzU for <apps-discuss@ietfa.amsl.com>; Wed, 29 May 2013 00:35:32 -0700 (PDT)
Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5991421F8EBB for <apps-discuss@ietf.org>; Wed, 29 May 2013 00:35:32 -0700 (PDT)
Received: by mail-ea0-f171.google.com with SMTP id b15so5112729eae.30 for <apps-discuss@ietf.org>; Wed, 29 May 2013 00:35:31 -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; bh=XQ+2EdVjcHFyxFBTowFq/BIrmSf97JiGBKrBjRzlYrM=; b=mw+uHfAT/QgssdfQI+LJnJFgT2bP0+JL6zhsYUyIzHg2z50WaR1iubUek+wCZzl4/9 XN5K9knwbJB0O2KGWMOKABYogU3i9Bkn3ET6JS/0c3Aol1WgzVu+pKMgoyUMjgg0plYf PlR4d5EbuSvdEY1UbgpkPDgqr8mZKKJu4TF0r9Ksjb1lZdgEP94hkyDnhoLbaCExqBgc mKnK98JdHaCrjjlbba3+DzZNkFG8rzBbQ+xsKO+/6w2miggnrhoPecQViVgu24C+3UgE Bz+hxMryaPGcB3iuA/ClM5tRqr2xoX7IakswCNJrrddg/pvdFP7AVNODOKGq1BTwFF6E UXgQ==
X-Received: by 10.15.76.9 with SMTP id m9mr1173967eey.146.1369812931297; Wed, 29 May 2013 00:35:31 -0700 (PDT)
Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id y2sm52143574eeu.2.2013.05.29.00.35.28 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 May 2013 00:35:30 -0700 (PDT)
Date: Wed, 29 May 2013 11:35:27 +0400
From: Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Message-ID: <FEB564CAAF9B47B8BE41F0BBE8556650@gmail.com>
In-Reply-To: <51a54dfa.086f0e0a.693f.2ff4SMTPIN_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>
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="51a5afbf_3494b2fb_1b1"
Cc: link-relations@ieft.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] NEW RELATION: property and context
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 07:35:34 -0000

James, Markus, Thanks for taking discussion further! I'm at work right now and will write detailed responses later.

@Markus

> I would really like to understand the differences but so far I haven't seen any. Ioseb, maybe a couple of more concrete examples about how you see the two rels being used would help a lot. And maybe also mention why collection/item or describes/describedBy wouldn't work for those examples.

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

*** 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.  What i want to say here it's a simple relationship between two resources without any descriptions etc…

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

Hope these examples will help! will write more later today. Thanks again!

cheers,
isoeb


On Wednesday, May 29, 2013 at 4:38 AM, Markus Lanthaler wrote:

> On Wednesday, May 29, 2013 2:21 AM, James M Snell wrote:
> > > James, did you read all the discussion? Ioseb made it quite clear
> >  
> > that his
> > > "context" is intended to be used completely different than JSON-LD's
> > > context. I'm still not sure I understand its semantics.
> > >  
> >  
> >  
> > Yep, I saw that and purposefully chose to ignore it :-) ... given the
> > general definition of "context" given in the draft, use for json-ld
> > type scenarios is not ruled out.
> >  
>  
>  
> Well.. the problem I have with the current I-D is that even after all these discussions I still don't understand what "context" is supposed to mean. Quoting the I-D:
>  
>  
> When included in a response, the "context" link relation identifies a
> target resource that represents a context document of which the
> context resource is a member.
>  
> For example, if a resource represents the property of a photo, that
> same resource may include link to a resource which the property
> belongs.
>  
> Taking the second paragraph, wouldn't the "describes" relation achieve just that? Quoting the abstract of RFC6892 which defines "describes":
>  
> This specification defines the 'describes' link relation type that
> allows resource representations to indicate that they are describing
> another resource. In contexts where applications want to associate
> described resources and description resources, and want to build
> services based on these associations, the 'describes' link relation
> type provides the opposite direction of the 'describedby' link
> relation type, which already is a registered link relation type.
>  
>  
> I would really like to understand the differences but so far I haven't seen any. Ioseb, maybe a couple of more concrete examples about how you see the two rels being used would help a lot. And maybe also mention why collection/item or describes/describedBy wouldn't work for those examples.
>  
>  
> Cheers,
> Markus
>  
>  
> --
> Markus Lanthaler
> @markuslanthaler
>  
>