Re: Issue-14: as:Link complexity

Current topic https://github.com/jasnell/w3c-socialwg-activitystreams/pull/100

> On 21 Apr 2015, at 18:24, James M Snell <jasnell@gmail.com> wrote:
> 
> Yes, as:Link is still needed. See the example I gave previously. In
> many cases, the intent of the publisher is to describe properties of
> the *reference* and not the *object*. Publishers are given the choice
> of which to use. I'm absolutely -1 on removing as:Link.

ok, I see that we are moving in the right direction with the new examples from pull request 100. But it is not quite work right for content negotiated resources. Imagine I am writing a JavaScript client and I want to display an image for an application, but I want my JavaScript to work on all browsers with minimal effort - that is I don't want to keep for each browser a list of types of preferred mime types it supports. So I'd like to just be able to follow the as:image relation and get the URL of the content negotiated resource.

The following is allowed by pull request 100 version and is great for that:

</application/123> a as:Application ;
  as:displayName "My Application" ;
  as:image </application/image> .
Here a piece of JS can follow the as:image relation and create the following html template <img src="/application/image">  that can display in any browser. Great! No need to know what each browsers image capacities are.

Now I suppose the Link type is needed for clients that know a lot more about the browser they are working in and that can choose the specific representation. If as a AS2.0 publisher I want to use the pull 100 proposed spec to also cater to those client I'd have to do the following:

</application/image> a as:Link;
   as:href </application/image.png>; 
   as:mediaType "image/png" ;
   as:href </application/image.jpeg> ;
   as:mediaType "image/jpeg" .
But since RDF triples are not ordered that would be equivalent to the following:

</application/image> a as:Link;
   as:href </application/image.png>; 
   as:mediaType "image/jpeg" .

</application/image> a as:Link;
   as:mediaType "image/png" ;
   as:href </application/image.jpeg> ;
What this shows is that there is no way to specify the mime types for the particular representation. This is more easily seen in the graph  format  where the above graph translates to the following:

 <https://cloud.githubusercontent.com/assets/124506/7269783/23049d9e-e8d7-11e4-86ce-d78dac68d032.png>
But what we really need is that the mime type be attached to the final representation resource not the content negotiation one. ( i.e. to image.jpeg not image ) Like this:

 <https://cloud.githubusercontent.com/assets/124506/7269858/978eb5dc-e8d7-11e4-8abb-126be2242144.png>
And indeed RFC 5988 <https://tools.ietf.org/html/rfc5988> the Link spec confirms this with the following text:

The "type" parameter, when present, is a hint indicating what the media type of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Type header of a HTTP response obtained by actually following the link. There MUST NOT be more than one type parameter in a link-value.


Social Web Architect
http://bblfish.net/