- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 22 Jul 2014 08:52:02 -0700
- To: Owen Shepherd <owen.shepherd@e43.eu>
- Cc: public-socialweb@w3.org
- Message-ID: <CABP7RbeJrDXLe=Pf0OqbyoiGe9+czWOBwhRdATkaU5zxvYsziw@mail.gmail.com>
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