Re: Issue-14: as:Link complexity

> On 22 Apr 2015, at 19:31, Benjamin Young <byoung@bigbluehat.com> wrote:
> 
> 
> The first example matches existing methods for expressing content negotiate-able variations of a resource—such as `Link:` headers.
> 
> In HTTP, you’d write the example as:
> ```
> Link: <http://example.org/image>; type="image/jpeg"
> Link: <http://example.org/image>; type="image/png"
> ```

You need to specify the relation in the HTTP Link headers. It's all a bit upside down sytax there. The
subject of the resource is the resource that is returning the document, the first url is the object, and the relation needs to be specified with a rel or rev attribute. See https://tools.ietf.org/html/rfc5988

So if you want to express the following graph, which includes an extra relation to the content negotiated resource




you would have to do it like this

Link: <image.jpeg>; rel="image"; type="image/jpeg"
Link: <image.png>; rel="image"; type="image/png"
Link: <image>; rel="image"

Perhaps you can have this too:

Link: <image>; rel="image"; type="image/*"

though of course the image relation should have as range the class of all images, so that it is unecessary to express this.

But you could just as well express the following graph with Link headers too.


like this

Link: <image>; rel="image"
Link: <image.jpeg>; anchor=<image>; rel="alternate"; type="image/jpeg"
Link: <image.png>; anchor=<image>; rel="alternate"; type="image/png"

The advantage of this second graph is that it expresses that the image has two variants, which information is lost in the first graph. ( In the first graph nothing tells us that those images are variants of each other, so a javascript api would perhaps even need to show all of them or run image analysis software to compare them somehow! )

Ie it seems in short that we have the rule

{ ?x as:image ?img.
  ?img iana:alternate ?alt . } => { ?x as:image ?alt }

but the inverse cannot be deduced.

Anyway, as a conclusion, given that both graphs can be expressed in the Link header, we cannot use it to help as criteria to select a good ontology for us. Which is good.

> 
> The second option (using an array as the value of `mediaType`) while less verbose, feels like a departure from current practice and also ties extension of the expression to the non-content-negotiated resource and limits the ability to talk about "the jpeg variation" and "the png variation" in specific.
> 
> So, +1 for the more familiar (however more verbose) first option.
> 
> I'm new here, so apologies if this has already been covered, etc, my apologies.
> 
> Thanks!
> Benjamin
> --
> Developer Advocate
> http://hypothes.is/
> 
> http://bigbluehat.com/
> 
> 
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Wednesday, April 22, 2015 12:37 PM
> To: henry.story@bblfish.net
> Cc: Robert Sanderson; Elf Pavlik; public-socialweb@w3.org; Evan Prodromou
> Subject: Re: Issue-14: as:Link complexity
>   
> 
> 
> {
> 
>   "@type": "Application",
> 
>   "image": [
> 
>     {
> 
>       "@type": "Link",
> 
>       "href": "http://example.org/image",
> 
>       "mediaType": "image/jpeg"
> 
>     },
> 
>     {
> 
>       "@type": "Link",
> 
>       "href": "http://example.org/image",
> 
>       "mediaType": "image/png"
> 
>     }
> 
>   ]
> 
> }
> 
>  
> 
> Either that, or we change mediaType to support multiple values.
> 
>  
> 
> 
> {
> 
>   "@type": "Application",
> 
>   "image": {
> 
>     "@type": "Link",
> 
>     "href": "http://example.org/image",
> 
>     "mediaType": ["image/jpeg", "image/png"]
> 
>   }
> 
> }
> 
>  
> 
> The former works today with no modifications. The latter would be a minor modification.
> 
>  
> 
> - James
> 
>  
> 
> 
> On Wed, Apr 22, 2015 at 9:31 AM, henry.story@bblfish.net <henry.story@bblfish.net>  wrote:
> 
> James Snell wrote:
> 
> 
> One, href and mediaType are defined as functional properties of as:Link. 
>  In which case the problem is: how do you deal with content negotiated resources?
> To develop this further: I was trying to get you to consider the case where there is one image with a number of different content negotiated representations - which is what web architecture  enables for the sanity of all developers. So if you don't allow that, you don't allow something pretty important for the system we are trying to build, and one that LDP is constantly using. Hence the SWWG  issue-14 on "as:Link complexity" which you  argued should be closed for lack of details. So I am providing arguments here as to why it is not just complex but does not answer an important  need. 
> Another way to put the question is: does as:image allow  its object to be a content negotiated image? 
> I don't think it can, because you end up with a contradiction. Let's do a reductio ad absurdum, and assume it can be.
> Since you allow us to have
> 
> <application> as:image _:b0._:b0 as:href <image.jpg> ._:b0 as:mimeType "application/jpeg"   . then it has to be possible to replace the blank node _:b0 with  a URL for a content negotiated image, which we'll call <image>.  This would give us: 
> 
> <application> as:image <image> .<image> as:href <image.jpg> .<image> as:mimeType "application/jpeg"   . Assume the following is true of <image>
> 
> Then we have to arbitrarily choose one of the content negotiated representations as the object of your as:href and as:mimeType values.  Or to put it as a question: which of the red lines are we meant to choose in the following diagram?
> 
> If as:href and as:mimeType are  functional relations they cannot point to two different things, and the choice of which representation they point to cannot be arbitrary. So as a consequence you have ended up creating a as:image relation  whose domain is a specific representation resource, which won't be correct if anyone points it to a resource that has multiple representations. ( and this is our reductio )
> Note that this won't be the case just for the objects of the  as:image relation  but it will be the case for any thing that can be of type as:Link .  This immediately excludes such things as LDPRGs that can  be in Turtle, JSON-LD or even micro-formats. So you are oddly making it logically impossible to use this with LDP.
> Now as I think there are a number of reasons why you ended up in this conundrum, which I think can be explained in part by the tension you feel between making an ontology and thinking  also about how it will look in one of the preferred formats. But we have to do here a job of reverse knowledge engineering to extract the semantics behind the original format of Atom XML, by considering its use, and this type of work can lead to some unexpected  conclusions.
> But luckily the way you have modelled the atom <link> xml  from which it was agreed at the last conf call that Activity Streams is rooted, is not the only way to model it. That is the link element as found in this example taken from RFC  4287
> 
> <entry>       <title>Atom draft-07 snapshot</title>       <link rel="alternate" type="text/html"        href="http://example.org/2005/04/02/atom"/>       <link rel="enclosure" type="audio/mpeg" length="1337"        href="http://example.org/audio/ph34r_my_podcast.mp3"/>       <id>tag:example.org,2003:3.2397</id>       <updated>2005-07-31T12:29:29Z</updated>       <published>2003-12-13T08:29:29-04:00</published>...</entry> 
> can be modelled differently as I argued in issue  #98 "removing the as:Link element. If one considers it carefully I argued there, these are just reifications that we no longer need to use.  But I won't repeat here what I wrote there yesterday.
> 
>  
> 
> Hope that helps show how at least the RDF framework can allow us to have very detailed and reasoned debates on technical issues, that  would otherwise just bite implementers futher down the road.
> 
>  
> 
> Henry
>      
> <image001.png><image002.png>

Social Web Architect
http://bblfish.net/