- 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