Re: Issue-14: as:Link complexity

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>

 <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?

 <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