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

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sun, 26 May 2013 15:51:14 +0400

Hi Mike,

Thanks for response!

> How are these different from the "collection" and "item" link relations?
> IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"?

It depends how we look at things. For example if if we've a resource that is a photo(or video etc...) we can not describe it as a collection. If we've resource which is a property of that photo we can indicate the context resource of this photo with the "context" link relation, as i understand and see it the "collection" link relation doesn't properly describe photo which definitely is not a collection of items itself.

Another example is a file which has various attributes(or properties), if for example i want to express these properties of the file as links i think the "property" link relation will be more correct rather than the "item" link relation IMHO.

ioseb 

On Sunday, May 26, 2013 at 3:38 PM, mca wrote:

> How are these different from the "collection" and "item" link relations?
> IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"?
> On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" <[email-masked] (mailto:[email-masked])> wrote:
> > Dear All, 
> > 
> > I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 
> > 
> > Description: 
> > 
> > - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. 
> > - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases
> > 
> > - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource.
> > - The "context" Link Relation Type: 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.
> > 
> > 
> > Could you please review?
> > Thanks in advance!
> > 
> > 
> > Best regards,
> > ioseb
> > -- 
> > Ioseb Dzmanashvili
> > AzRy LLC
> > Software Architect
> > #8, Chachava str.
> > Tbilisi, 0159, Georgia
> > 
> > Mobile: +(995) 99753388
> > github.com/ioseb (http://github.com/ioseb)
> > twitter.com/iosebi (http://twitter.com/iosebi)
> > 
> > 
> > 
> > _______________________________________________
> > apps-discuss mailing list
> > [email-masked] (mailto:[email-masked])
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >

---

From: mca <[email-masked]>
Date: Sun, 26 May 2013 07:52:18 -0400

Ioseb:

so your thinking is that the attributes of a file is not a "collection"?

mca
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Sun, May 26, 2013 at 7:51 AM, Ioseb Dzmanashvili <
[email-masked]> wrote:

> It depends how we look at things. For example if if we've a resource that
> is a photo(or video etc...) we can not describe it as a collection. If
> we've resource which is a property of that photo we can indicate the
> context resource of this photo with the "context" link relation, as i
> understand and see it the "collection" link relation doesn't properly
> describe photo which definitely is not a collection of items itself.
>
> Another example is a file which has various attributes(or properties), if
> for example i want to express these properties of the file as links i think
> the "property" link relation will be more correct rather than the "item"
> link relation IMHO.
>
> ioseb
>
> On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" <
> [email-masked]> wrote:
>
>  Dear All,
>
> I've submitted new draft for the "property" and "context" link relation
> types:
> http://tools.ietf.org/html/draft-property-and-context-link-relations-00
>
> Description:
>
> - This specification defines link relation types that may be used to
> express the relationships between a resource and associated properties or
> between a resource and it's context.
> - The "property" and "context" link relations are intentionally generic,
> and they can be used with multiple media types in a wide variety of use
> cases
> - The "property" Link Relation Type: When included in a response, the
> "property" link relation identifies a target resource that represents a
> property of the context resource.
> - The "context" Link Relation Type: 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.
>
> Could you please review?
> Thanks in advance!
>
> Best regards,
> ioseb
> --
> Ioseb Dzmanashvili
> AzRy LLC
> Software Architect
> #8, Chachava str.
> Tbilisi, 0159, Georgia
> Mobile: +(995) 99753388
> github.com/ioseb
> twitter.com/iosebi
>
> [email-masked]

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Sun, 26 May 2013 16:00:21 +0400

Mike,

> so your thinking is that the attributes of a file is not a "collection"?

No, i think that attributes of a file is a collection, but i do not think that a file is a collection of attributes. 

Another example:

If i have an article with a photo(or whatever else), does it makes that article collection of photos(or other properties which are part of that article)? If i'm viewing photo can i say that hey here is the collection which this photo belongs to? or wouldn't it be more precise if i say hey here is the context to which this photo belongs to?

ioseb 

On Sunday, May 26, 2013 at 3:52 PM, mca wrote:

> On Sun, May 26, 2013 at 7:51 AM, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> > Hi Mike,
> > 
> > Thanks for response!
> >

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Mon, 27 May 2013 12:06:15 +0400

Jan,

> Let's try a different way: What is a 'property'?

It's a data member. For example "title" or "summary" of an article.

ioseb  

On Monday, May 27, 2013 at 11:46 AM, [email-masked] wrote:

> 
> On 27.05.2013, at 09:36, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> 
> > 
> > > What is the difference exactly between a property and a link?
> > 
> > Sorry, i do not get this question? 
> 
> Let's try a different way:
> 
> What is a 'property'?
> 
> Jan
> 
> 
> > 
> > Cheers,
> > ioseb 
> > On Sunday, May 26, 2013 at 9:00 PM, Jan Algermissen wrote:
> > 
> > > Ioseb,
> > > 
> > > On 26.05.2013, at 13:21, Ioseb Dzmanashvili <[email-masked] (mailto:[email-masked])> wrote:
> > > 
> > > > Dear All,
> > > > 
> > > It feels a bit like reinventing RDF.
> > > 
> > > What is the difference exactly between a property and a link?
> > > 
> > > Jan
> > > 
> > > 
> > > > 
> > > > Description:
> > > >

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Thu, 30 May 2013 00:07:34 +0400

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

---

From: "Markus Lanthaler" <[email-masked]>
Date: Sat, 1 Jun 2013 01:30:59 +0200

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

Thanks a lot! This definitely makes replying much easier

--
Markus Lanthaler
@markuslanthaler