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 <http://activitystrea.ms/specs/json/1.0/#RFC4627> [RFC4627] String
>
> An IRI [RFC3987] <http://activitystrea.ms/specs/json/1.0/#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
> <http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#linkValue>
>
> A Link Value describing a resource providing a representation of the
> object. An object *MAY* contain a url
> <http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#url-attribute>
> 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
>
> }]
>
> }
>
>
>
>
>

Received on Tuesday, 22 July 2014 15:52:50 UTC