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

> >
> > 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"
>       }
>     ]
>   }
>

This was the first option indeed.
The second option in my proposal about reusing json-ld would look like:

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

That is json-ld for true/core object propoerties, and your current approach to links at the same level, also clearly distinct from json-ld (no @). I understand though that it breaks backward compatibility with 1.0 (but a "version" property may help in that sense, just like in json-rpc)

Yet a third option could be more in line with the previous example you made, but simplifying the way links are structured to reuse here again rels as key values.
Meaning:
  {
     "objectType": "note",
     "id": "http://example.org/notes/1",
     "links": [
       {
        "author": "urn:example:person:joe"
       },
       {
          "icon": "http://example.org/img/note.png"
       }
     ]
  }

Or even

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

walter

> 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.

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.

Received on Monday, 25 August 2014 08:24:33 UTC