RE: AS2 links

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: 22 July 2014 18:16
> To: Owen Shepherd
> Cc: public-socialweb@w3.org
> Subject: Re: AS2 links
> 
> There's a balance here. See below.
> 
> On Tue, Jul 22, 2014 at 9:50 AM, Owen Shepherd <owen.shepherd@e43.eu>
> wrote:
> > Why do we even have a rel property? I don't see any use of it which
> > couldn't be more succinctly expressed by using the property name. It
> > also breaks JSON-LD processing, by conflating a property of the link
> > (the relation) with the object.
> >
> 
> Imagine the following case. I have a objectType that represents an
> application. As is typical in many "app stores", the application may have
> multiple preview images with a single default or preferred preview. We can
> accomplish this concisely using something like:
> 
> {
>   "objectType": "application",
>   "displayName": "My Application",
>   "preview": [
>     {
>       "mediaType": "image/jpeg",
>       "url": "http://example.org/screens/app1.jpg"
>     },
>     {
>       "mediaType": "image/jpeg",
>       "url": "http://example.org/screens/app2.jpg"
>     },
>     {
>       "mediaType": "image/jpeg",
>       "url": "http://example.org/screens/app3.jpg",
>       "rel": "image"
>     }
>   ]
> }
> 
> Here, the third image is set up as both a preview image and the default
> display image for the object.

It seems like a relatively niche use case for what is a considerable increase in the difficulty in processing the content (i.e. it's no longer sufficient for the processor to just walk the attributes to find objects). 

I don't think the use cases justify the complexity (and, as said, it doesn't mesh well at all with JSON-LD processing)


> > I'm with you in being against a generalized url property; this is why
> > I want to see its' purpose defined. I very much want an easy to
> > extract property to which I can link a user so that they can view the
> object on its'
> > "home site". This is very much an important feature of the format, no?
> >
> 
> If I had my choice, the generic "url" property would be deprecated in favor
> of a specific Link Relation, such as "self" or "canonical".
> 
> {
>   "objectType": "image",
>   "self": "http://example.org/foo.jpg"
> }
> 
> Is semantically clear and tell's me exactly what I need to know without the
> need to overload "url".

*Neither* of us is proposing to overload "url".

All I'm looking for is
 * An unambiguous "source" attribute, which can be used by processors to find the content `to be embedded` (for example, in the case of an image object, this would contain the URI to be used as the value of an <img src=> property when rendering the object as HTML)
 * An unambiguous "link" attribute, which can be used by processors to link to the object on its' "home site". 
 * An unambiguous "this document" attribute, which can be used to refresh the ActivityStreams object

AS1 kind of makes a mess of the former, did an OK job of the former, and canonicalized the latter in the Activity Base Schema.

What is wrong with defining such properties in AS2? I'm not especially attached to the name of the "url" property, but I don't see compelling reason to change it.

As someone who has written two relatively in-depth applications dealing with ActivityStreams now, these are all pieces of data which I need to pull out *all the time*. Surely these things should be minimum friction?

> 
> > AS1 defines the url property to have this purpose. Why change it? What
> > was wrong with it as is, except for the "misuse" of it by the Media
> > Link and Collection types?
> >
> > Also, I wholeheartedly disagree with your use of the "self" relation
> > to point to the image file. To quote RFC 4287:
> >
> >    3.  The value "self" signifies that the IRI in the value of the href
> >        attribute identifies a resource equivalent to the containing
> >        element.
> >
> > There is also already precedence for using the self relation to point
> > to the ActivityStreams version of an object in AS1.
> >
> > Is there any compelling argument *against* defining a property to
> > contain a link to the (image|video|audio files) which define a
> > resource? Consider the property's values as analogous to the HTML5
> > <source> element
> >
> 
> The main argument that I can see is that we just end up duplicating the
> existing function of Link Relations. Why do so when we can reuse an already
> paved path?

I don't see any defined link relations which do pave said path.

Received on Tuesday, 22 July 2014 17:47:16 UTC