RE: AS2 links

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.

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?

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


From: James M Snell [mailto:jasnell@gmail.com] 
Sent: 22 July 2014 16:52
To: Owen Shepherd
Cc: public-socialweb@w3.org
Subject: Re: AS2 links

​The linking model within AS2 allows existing RFC5988 Link Relations to be
used directly as attributes on AS objects (see
http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#
linkValues). This means that we can already directly adopt existing link
relations such as "self" and "alternate" to do what you are suggesting.
Objects used as link values can also have a "rel" attribute that explicitly
specifies the relation.

So, for instance, with the spec as currently written, we can do:

{
  "objectType": "image",
  "id": "http://example.org/api/image/sdashdkj", 
  "url": [  
    {
      "url": "https://example.org/api/image/sdashdk/thumb.jpg",
      "mediaType": "image/jpeg",
      "width": 128,
      "height": 128,
      "rel": "preview"
    },
    {
      "url": "https://example.org/api/image/sdashdk/image.jpg",
      "mediaType": "image/jpeg",
      "height": 1024,
      "width": 1024,
      "rel": "self"
    }
  ]
}​

Or, we can simplify that down to:

{
  "objectType": "image",
  "id": "http://example.org/api/image/sdashdkj", 
  "height": 1024,
  "width": 1024,
  "mediaType": "image/jpeg",
  "self": "https://example.org/api/image/sdashdk/image.jpeg",
  "preview": {
    "url": "https://example.org/api/image/sdashdk/thumb.jpg",
    "mediaType": "image/jpeg",
    "width": 128,
    "height": 128
  }
}​

Either would be valid under the current spec with the latter being
preferred over the former. Ultimately, I would much rather see more direct
use of the registered Link Relations (as in the second example) and less use
of the more generic/generalized "url" property.

- James

On Tue, Jul 22, 2014 at 8:29 AM, Owen Shepherd <owen.shepherd@e43.eu>
wrote:
ActivityStreams 1.0 largely defines the precedence of using the “url”
property as a link to a “user viewable” version of the object (e.g. a http
link to a web page which represents the object):
url 
JSON [RFC4627] String
An IRI [RFC3987] identifying a resource providing an HTML representation of
the object. An object MAY contain a url property 
(The use HTML here is probably overly restrictive, but the intent is clear)
 
It makes some missteps:
•         For media links, url is the IRI of the media resource (e.g. an
image)
•         For collections, url is the IRI of a the collection in JSON form.
This is contradictory to the above, as collections are objects
 
These are best interpreted as bugs in the spec, IMO.
 
The AS2 ED defines url as follows:
url
Link Value
A Link Value describing a resource providing a representation of the
object. An object MAY contain a url property. 
 
This provides no context for what the “url” property actually points to.
The examples in the spec then use the “url” property to refer to multiple
different resources: a web page representing a user, the actual image in the
case of an “image” object, etc. The “url” property provides no useful meta
data with regards to what its’ pointing to. This is useless.
 
I suggest that we split the two conflated roles into two separate
properties:
•         url: The IRI of a resource which represents a human readable
representation (for example, a HTML document) of this object
•         href? src?: A link value containing one or more machine
processable representations of this resource. For example, for an object of
type image, this could provide multiple resolution images of the object
•         We might also codify self, The IRI at which the JSON form of this
resource can be found. This would simply be codifying use of the already
defined link relation for this purpose.
 
We might add language to the spec as follows:
•         The id of an object SHOULD be the IRI of a resource which can be
dereferenced to return an up to date description of the object in this
format.
•         In cases where the id does not correspond to an IRI
dereferencable as above, then the object SHOULD contain the self property,
set to an IRI which may be dereferenced for an AS2 representation of the
object. 
•         In the absence of values for the url and href properties,
processors MAY attempt to dereference the IRI that is the object’s id for
the resources to which these properties would normally point. This means
that you can just put the URI of an image in an Object’s image property and
things will still work; no need to actually construct an image object.
Obviously in this case it may not really be possible for clients to interact
with the image as a discrete entity.
 
This actually has brought me back around to thinking that the AS1 concept
of a media link was correct, just incorrectly applied. I feel that they’re
actually very useful, but were expressed incorrectly in AS1. The importance
of such objects is in sufficiently expressing the semantics of the data: if
all the resolution variations of an image become independent objects, then
what you have is not a meaningful object graph, but rather an object soup
 
AS1 example:
{
       “objectType”: “image”,
       “id”: “https://example.com/api/image/sdashdkj”,
       “url”: “https://example.com/person/image/sdashdkj”,
       “image”: { “src”: “https://example.com/api/image/sdashdkj/image.jpg”
}
}
 
Proposed AS2 example:
{
“objectType”: “image”,
“id”: “https://example.com/api/image/sdashdkj”,
“url”: “https://example.com/person/image/sdashdkj”,
“href”: [{ 
“src”: “https://example.com/api/image/sdashdkj/thumb.jpg”,
“mimeType”: “image/jpeg”,
“width”: 128, “height”: 128
}, { 
“src”: “https://example.com/api/image/sdashdkj/image.jpg”,
“mimeType”: “image/jpeg”,
“width”: 1024, “height”: 1024
}]
}