RE: Issue-14: as:Link complexity

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"
```

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