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"
> <https://www.w3.org/Social/track/issues/14> which you argued should be
> closed
> <https://lists.w3.org/Archives/Public/public-socialweb/2015Apr/0057.html> 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>
>
> [image: linkinfoloss-improved2]
> <https://cloud.githubusercontent.com/assets/124506/7276753/4e46bd18-e90c-11e4-947c-0930f443f2a2.png>
>
> 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?
>
> [image: linkinfoloss-reductio]
> <https://cloud.githubusercontent.com/assets/124506/7278916/a1e6bcaa-e918-11e4-9653-054a18538a63.png>
>
> 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 <https://tools.ietf.org/html/rfc4287>
>
> <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
> <https://github.com/jasnell/w3c-socialwg-activitystreams/pull/98#issuecomment-94702056>.
> 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
>