Re: Remove "rel" from Link

> ☮ elf Pavlik ☮ <mailto:perpetual-tripper@wwelves.org>
> 03 November 2014 18:17
>
> I still don't understand, for example in
>
> {
>    "@context": "http://www.w3.org/ns/activitystreams",
>    "@type": "http://example.org/types/application",
>    "@id": "http://example.org/application/123",
>    "displayName": "My Application",
>    "image": {
>      "@id": "http://example.org/application/123.png",
>      "@type": "urn:example:image",
>      "mediaType": "image/png"
>    }
> }
>
> We don't need as:Link here, of course we can add it to "@type" just to
> hint it as dereferencable. If we want to add additional information
> besides just using "@id" as value, we already need to use embeded
> object. Of course we can embed only as much of known to us properties as
> we want to (not sure what exactly you meant by "do not need to be
> represented as complete objects".)
>
> I think we can define rdfs:range of "image", "icon" and "url" simply as
> as:Object.

So, the reason I initially objected to complete unification of "Objects" 
and "Media Links" from AS1, and the reason I continue to do so, is that 
they continue to be semantically different objects in the social graph

To consider the two most popular social silos for a moment, and a case 
of where they treat things very differently:

  * On Facebook, your profile picture is an Image in the same sense as
    any other Image you upload. When you click on it in the web UI, it
    opens up the underlying Image object, and you can interact with it
    as with any other object in your social graph - you can like it, you
    can share it, you can comment on it, etc
  * On Twitter, your profile picture is a "dead image". It is not an
    object in the social graph.

Another example: If I upload a video, then the video itself is a live 
object in my social graph. That video has an image (presumably a still 
image of one of the frames or some other placeholder content that will 
be displayed before I click play). That image shouldn't be a live object 
in the social graph, because it is integrally bound to my video.

The use cases are subtly different, but I don't think the difference is 
insurmountable. We need to do a few things:

 1. Distinguish the use case of "embeddable media" and the usecase of
    "link relations". If we are to keep the latter, that is a separate
    matter (and links should retain the as:Link name)
 2. The basic, non-social-graph media data is typed as as:Media. This
    object SHOULD NOT have a global ID. It will have various properties
    pointing at the media and covering its' content type, but shouldn't
    have any descriptive properties IMO (its purely an augmentation of
    the containing object)
 3. Media which is an interactable social graph object is an
    as:MediaObject, which is a sublass of as:Object and as:Media.
    as:MediaObject should be considered an "abstract type"; objects
    SHOULD be typed as some subclass of as:MediaObject
 4. as:Image, as:Video, as:Audio, etc, become subclasses of as:MediaObject

This leaves two remaining questions:

  * How do we handle multiple variants of a piece of media? (e.g.
    multiple codecs and/or resolutions of a video). This probably
    requires another level of indirection (sigh)
  * How do we support embedding "non-trivial" content/fallback. AS1 had
    embedCode, do we bring back something like that? (Maybe a URI to
    embed as an iframe?)

How I envisage this working:
{
     "@type": "as:Article",
     "@id": "https://buzznews.example/2014/14/03/see-this-funny-video"
     "title": "See this funny video!",
     "author": {
         "@type": "as:Person",
         "@id": "https://johnsmith.example"
         "displayName": "John Smith",
         "icon": {
             // "dumb" icon. as:Media implied by as:icon.
             "src": "https://johmsnith.example.com/displaypic.jpg"
         },
         ...
     },
     // "Related" video - probably "headline"
     "video": {
         // Vivified object!
         "@type": "as:Video",
         "@id": "https://yourtube.example/as78678j",
         "src": [
             // Proposed multiple source syntax. Derived from HTML5 
<source> parameters.
             // We probably want to just do "resolution" or "res" for 
widthxheight because srcset is a backcompat hack not applicable to us
             {"href": "https://yourtube.example/as78678j .mp4", "type": 
'video/mp4; codecs="avc1.42E01E, mp4a.40.2" '},
             {"href": "https://yourtube.example/as78678j .mkv", "type": 
'video/webm; codecs="video/webm; codecs="vp8, vorbis" '},
         ],
         "image": { "src": "https://yourtube.example/as78678j .jpeg "  },
         ... // comments, etc
     },
     // "Caption image" - maybe suppressed by the video, but e.g. a feed 
reader might use this in an overview page
     "splash": { // * (See end)
         "src": "https://buzznewscdn.example/dasdljkah7893yiu.jpg"
     },
     "content": /* article body */,
     ... // comments etc
}

People's thoughts?

* splash: I'm not sure what to call this or if its necessary, but the 
intention is to imply an image which its' explicitly allowed to scale 
and, more importantly, crop. Basically you should expect that this image 
is "center cropped".