Re: [AS2] Deprecate "url" in favor of "id" and "self" link relations

On Thu, Aug 21, 2014 at 3:13 PM, Goix Laurent Walter
<laurentwalter.goix@telecomitalia.it> wrote:
>
> Hi all,
>
> i have to say that i am a bit lost here in seeing all these alternative proposals. in particular i am  bit skeptical about the mix of AS-defined property names (objectType, id, etc) with potentially *any* iana link rel to be used as property name at the same level. I envision syntactic and semantic conflicts/overlaps in the future as we don’t know how the iana link rel registry will evolve…
>

A couple of points on this:

1. The AS2 draft deals with this issue in Section 3.4
(http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#linkValues).
Specifically, any valid RFC 5988 compliant link relation can be used
as an object property unless the link relation conflicts with the
definition of any of the core attributes. In other words, the AS2
vocabulary is given precedence.

2. If new link relations are added to the IANA registry over time, and
those happen to conflict with any of the properties defined by the AS2
vocabulary, the AS2 vocabulary wins.

3. Deprecation or Update of a currently registered link relation would
require the successful publication of an IETF RFC... which means the
requester would have to make a pretty darn good case as to why the
existing link relation ought to be changed or removed. To date, no one
has done this, especially since it's easier just to mint a new link
relation and ignore ones you don't want to use.

> in that sense it would be safer to separate, semantically & syntactically, what relates to the true object characteristics (basically type & id, displayName maybe and little more), from any “link” that represents or relates to it (for which link rels are powerful)
> Two alternative could (at least) be:
>
>  via a specific *container* “links” property at object level (which syntax may be taken from webfinger’s jrd or simplified), which would embed all the link rels
> by leveraging possibly json-ld to distinguish the “true object properties” from the additional properties at the same level (which at this point could stay as per James’ latest proposal of using directly link rels)
>

I personally don't see much real distinction between "true object
properties" and the link relations. There are many of the existing
properties that double perfectly well as link relations.

For instance, compare:

  {
    "objectType": "note",
    "id": "http://example.org/notes/1",
    "author": "urn:example:person:joe",
    "icon": "http://example.org/img/note.png"
  }

To:

  {
    "objectType": "note",
    "id": "http://example.org/notes/1",
    "links": [
      {
       "rel": "author",
       "href": "urn:example:person:joe"
      },
      {
       "rel": "icon",
       "href": "http://example.org/img/note.png"
      }
    ]
  }

In both cases, we can interpret the "author" and the "icon" in exactly
the same way.

If you look at the vocabulary
[http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html]
all of the properties defined as type LinkValue work equally well as
Link Relations (which is why they're defined as Link Values :-) ...).
The approach that AS2 takes is far more concise. Yes, in theory, there
is a *possible* risk of conflicts rising up in the future but those
are not likely to cause any real problem in practice.

- James

>
> walter
>
> De : James M Snell
> Envoyé : ‎jeudi‎ ‎21‎ ‎août‎ ‎2014 ‎22‎:‎37
> À : activity-streams@googlegroups.com
> Cc : public-socialweb@w3.org
>
> On Thu, Aug 21, 2014 at 1:15 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> [snip]
> >>
> >> Can you please give some concrete examples? I'll see if I can explain
> >> the rationale for the changes using those examples.
> >>
> >
> > I hope you will understand if I say this will take a bit of extra time to
> > put together. I'll try to do so soonish :-)
> >
>
> +1
>
> > One simple example, a video object in AS1 looks like
> >
> >  {
> >     "objectType": "video",
> >     "displayName": "Cute little kittens",
> >     "embedCode": "<video width='320' height='240'
> > controls='controls'>...</video>",
> >     "stream": {
> >       "url": "http://example.org/my_video.mpg"
> >     },
> >     "image": { "url": "http://example.com/my_video.mpg.jpg"},
> > }
> >
> >
> >
> > Per your AS2 examples, this image would go from being a Media Link to an
> > Object. Therefore, it would "decompose" into a separate object, and would
> > require fetching from the database by processors.
>
> How I would represent this in AS2 would be:
>
> {
>   "objectType": "video",
>   "displayName": "Cute little kittens",
>   "content": "<video width='320' height='240'> controls='controls'>...</video>",
>   "id": "http://example.org/my_video.mpg",
>   "image": "http://example.com/my_video.jpg"
> }
>
> "image" is defined as a Link Value, which means it can be either an
> IRI or an Object. The object form is only required if you wish to
> define additional properties about the referenced resource.
>
> >
> > This object is not meaningful. It has no purpose on it's own, and no
> > identifier. In other words, it is pointless it being an object; hence why I
> > like the distinction between media links and objects, because they avoid
> > such meaningless objects.
>
> Unless you're specifying additional properties for the linked
> resource, it shouldn't need to be expressed as a JSON object at all
> (as in my example above).
>
> - James
>
> 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.

Received on Friday, 22 August 2014 00:08:12 UTC