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 17:49:54 UTC