Re: **PROPOSED** AS2 spec update

> Markus Lanthaler <mailto:markus.lanthaler@gmx.net>
> 07 November 2014 19:41
>
> I think the crucial thing here is that we get rid of the "rel" 
> property and use "proper" properties and types instead. The 
> representation above makes it quite clear what the value of "image" is 
> and why it is there. I expect people to struggle to understand why you 
> would use
>
I am completely agreed on the removal of rel. Direct properties are 
preferable.

However, there is a very good reason for something like "as:Link", even 
if I am opposed to the over-general name, and that is the fact that 
there are two types of media:

  * There are those which are not "Social objects" themselves. Think of
    the video attached to a news story, or the image at the top of a
    newspaper article. These are not distinct things - you cannot
    comment on them individually, for example; you must comment on their
    containing story.
  * There are those which are "Social objects". When you upload a video
    or image to your social stream, that should be a social object. You
    can comment on the video, like it, share it, etc.

So there are two cases:

 1. A post's "image" member points to just an image file. It is an
    accompanying image, not a social object itself.
 2. A post's "image" member points to an image social object.

So the former is a blank node with a member pointing at the real object, 
because that signifies "this really is a component of its' parent 
object" as opposed to "this is a distinct object in its' own right", and 
the latter is a node with a URI, which hopefully points at the place I 
can grab an up-to-date AS2 document describing the office (this 
"hopefully" is expanded to a MUST in the ActivityPump submission I 
posted, except for certain special cases)

This also protects provenance, because I don't want photos morphing into 
movies in my database because two people described the same URI 
differently. The use of blank nodes prevents that. (ActivityPump defines 
a mechanism for ensuring provenance, but it relies upon object IDs being 
dereferencable to get a canonical version)

You can find my suggestion here:
http://lists.w3.org/Archives/Public/public-socialweb/2014Nov/0031.html

Its' a relatively concise, compact specification. It does the smallest 
thing which can work. It makes both cases have the same structure - just 
the object case has an ID (defining the object) and possibly comes with 
a few more properties.

I think currently we have an overgeneral solution which doesn't mesh 
with the needs of the smaller problem domain to which it actually applies.

     - Owen