RE: AS2 links

This is actually very similar to the model ActivityStreams 1 uses, see the base schema:

                https://github.com/activitystreams/activity-schema/blob/master/activity-schema.md#ld

                (You’ll have to scroll down a bit more after that to find it, because of a formatting error. I never did understand why that transitioned from a link to a nice navigable HTML document into a broken GitHub page…)

 

I think James’ intention was to simplify AS2 by making the links “first class” objects; however I’m not sure it’s viable. The link relations and RDF/JSON-LD models are subtly different and incompatible. I’m beginning to think that perhaps the attempt to unify them is misguided because of this.

 

If the decision to re-adopt the “links” member were done, I’d be in favour of incorporating that segment of the JRD spec by direct reference, enabling people to reuse that segment of their JRD parser. This is especially worthwhile considering that WebFinger and ActivityStreams are likely to be used together (in order to resolve username@domain format account IDs)

 

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] 
Sent: 22 July 2014 17:24
To: James M Snell; Owen Shepherd
Cc: public-socialweb@w3.org
Subject: R: AS2 links

 

Hi all,

 

I recognize the need for a simple “url” property as a pointer to the object itself. However I would definitely support more semantics in the “links” that can be attached to objects. For that purpose I would recommend to consider the work done on “links” (that could become a new property array) by Webfinger (http://tools.ietf.org/html/rfc7033#section-4.4.4) . 

Going more into details this could mean for example to slightly update the current LinkValue definition of as2 as follows:

-          Create a new “links” property array to limit overloading the concept of “url”

-          Renaming the “url” (under link value type) as “href”

-          “title” and “properties” may be of interest for this context as well

-           “mediaType” (instead of “type”) could stay as it is now in as2, since this can avoid confusion with AS object “types”

 

walter

 

Da: James M Snell [mailto:jasnell@gmail.com] 
Inviato: martedì 22 luglio 2014 17.52
A: Owen Shepherd
Cc: public-socialweb@w3.org <mailto:public-socialweb@w3.org> 
Oggetto: 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 <mailto: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

}]

}

 

 

 


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.