RE: AS2 links

Example 1: An image

{
 "objectType": "image",
 "id": "http://api.blog.example.com/object/39250E30-A0A6-46D5-A9AE-3CCE5BB481ED",
 "url": "http://blog.example.com/2015/01/01/daww",
 "displayName": "D'Aww",
 "content": "<p>Kitteh!</p>",
 "src": "http://api.blog.example.com/object/39250E30-A0A6-46D5-A9AE-3CCE5BB481ED/kitteh.jpg"
 }

Example 2: A person
{
 "objectType": "person",
 "id": "acct:johnsmith@example.com",
 "self": "http://api.example.com/user/johnsmith",
 "url": "http://example.com/~johnsmith",
 "displayName": "John Smith",
 "image": {
  "id": "http://api.example.com/object/130BE593-B7CD-4B8F-8AD1-C1DDA349FCB0",
  "url": "http://example.com/~johnsmith/object/130BE593-B7CD-4B8F-8AD1-C1DDA349FCB0",
  "src": [{
   "type": "image/jpeg",
   "width": 128, "height": 128,
   "href": "http://api.example.com/object/130BE593-B7CD-4B8F-8AD1-C1DDA349FCB0/img?sz=128x128"
  }, {
   "type": "image/jpeg",
   "width": 1024, "height": 1024,
   "href": "http://api.example.com/object/130BE593-B7CD-4B8F-8AD1-C1DDA349FCB0/img"
  }]
 }
}

Basically:
 * id - as now
 * url - as defined for objects in AS1 - a link to which you can direct /humans/
 * src/href/source/whatever - somewhere I can dig out the embeddable bits.

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: 22 July 2014 18:49
> To: Owen Shepherd
> Cc: public-socialweb@w3.org
> Subject: Re: AS2 links
> 
> I may be misunderstanding what you're saying then, and since I think best
> when I see specific examples, can you give me one or two json examples that
> illustrate what you'd prefer to see?
> 
> On Tue, Jul 22, 2014 at 10:46 AM, Owen Shepherd <owen.shepherd@e43.eu>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: James M Snell [mailto:jasnell@gmail.com]
> >> Sent: 22 July 2014 18:16
> >> To: Owen Shepherd
> >> Cc: public-socialweb@w3.org
> >> Subject: Re: AS2 links
> >>
> >> There's a balance here. See below.
> >>
> >> On Tue, Jul 22, 2014 at 9:50 AM, Owen Shepherd <owen.shepherd@e43.eu>
> >> wrote:
> >> > Why do we even have a rel property? I don't see any use of it which
> >> > couldn't be more succinctly expressed by using the property name.
> >> > It also breaks JSON-LD processing, by conflating a property of the
> >> > link (the relation) with the object.
> >> >
> >>
> >> Imagine the following case. I have a objectType that represents an
> >> application. As is typical in many "app stores", the application may
> >> have multiple preview images with a single default or preferred
> >> preview. We can accomplish this concisely using something like:
> >>
> >> {
> >>   "objectType": "application",
> >>   "displayName": "My Application",
> >>   "preview": [
> >>     {
> >>       "mediaType": "image/jpeg",
> >>       "url": "http://example.org/screens/app1.jpg"
> >>     },
> >>     {
> >>       "mediaType": "image/jpeg",
> >>       "url": "http://example.org/screens/app2.jpg"
> >>     },
> >>     {
> >>       "mediaType": "image/jpeg",
> >>       "url": "http://example.org/screens/app3.jpg",
> >>       "rel": "image"
> >>     }
> >>   ]
> >> }
> >>
> >> Here, the third image is set up as both a preview image and the
> >> default display image for the object.
> >
> > It seems like a relatively niche use case for what is a considerable
> increase in the difficulty in processing the content (i.e. it's no longer
> sufficient for the processor to just walk the attributes to find objects).
> >
> > I don't think the use cases justify the complexity (and, as said, it
> > doesn't mesh well at all with JSON-LD processing)
> >
> >
> >> > I'm with you in being against a generalized url property; this is
> >> > why I want to see its' purpose defined. I very much want an easy to
> >> > extract property to which I can link a user so that they can view
> >> > the
> >> object on its'
> >> > "home site". This is very much an important feature of the format, no?
> >> >
> >>
> >> If I had my choice, the generic "url" property would be deprecated in
> >> favor of a specific Link Relation, such as "self" or "canonical".
> >>
> >> {
> >>   "objectType": "image",
> >>   "self": "http://example.org/foo.jpg"
> >> }
> >>
> >> Is semantically clear and tell's me exactly what I need to know
> >> without the need to overload "url".
> >
> > *Neither* of us is proposing to overload "url".
> >
> > All I'm looking for is
> >  * An unambiguous "source" attribute, which can be used by processors
> > to find the content `to be embedded` (for example, in the case of an
> > image object, this would contain the URI to be used as the value of an
> > <img src=> property when rendering the object as HTML)
> >  * An unambiguous "link" attribute, which can be used by processors to
> link to the object on its' "home site".
> >  * An unambiguous "this document" attribute, which can be used to
> > refresh the ActivityStreams object
> >
> > AS1 kind of makes a mess of the former, did an OK job of the former, and
> canonicalized the latter in the Activity Base Schema.
> >
> > What is wrong with defining such properties in AS2? I'm not especially
> attached to the name of the "url" property, but I don't see compelling
> reason to change it.
> >
> > As someone who has written two relatively in-depth applications dealing
> with ActivityStreams now, these are all pieces of data which I need to pull
> out *all the time*. Surely these things should be minimum friction?
> >
> >>
> >> > AS1 defines the url property to have this purpose. Why change it?
> >> > What was wrong with it as is, except for the "misuse" of it by the
> >> > Media Link and Collection types?
> >> >
> >> > Also, I wholeheartedly disagree with your use of the "self"
> >> > relation to point to the image file. To quote RFC 4287:
> >> >
> >> >    3.  The value "self" signifies that the IRI in the value of the
> href
> >> >        attribute identifies a resource equivalent to the containing
> >> >        element.
> >> >
> >> > There is also already precedence for using the self relation to
> >> > point to the ActivityStreams version of an object in AS1.
> >> >
> >> > Is there any compelling argument *against* defining a property to
> >> > contain a link to the (image|video|audio files) which define a
> >> > resource? Consider the property's values as analogous to the HTML5
> >> > <source> element
> >> >
> >>
> >> The main argument that I can see is that we just end up duplicating
> >> the existing function of Link Relations. Why do so when we can reuse
> >> an already paved path?
> >
> > I don't see any defined link relations which do pave said path.
> >

Received on Tuesday, 22 July 2014 18:02:13 UTC