- From: Owen Shepherd <owen.shepherd@e43.eu>
- Date: Tue, 04 Nov 2014 18:57:10 +0000
- To: James M Snell <jasnell@gmail.com>
- CC: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, "public-socialweb@w3.org" <public-socialweb@w3.org>
- Message-ID: <54592186.7050300@e43.eu>
> James M Snell <mailto:jasnell@gmail.com>
> 04 November 2014 03:35
> This seems to be getting a bit lost in the weeds. Let's keep the
> issues separate.
>
> The first issue is: "rel" as currently defined in the spec doesn't
> work the way it should and ought to be removed.
Agreed
> The second issue is in how the as:Link class is defined. Let me make
> sure there's no confusion on this point. as:Link is essentially a
> marker that indicates that the value of @id can be dereferenced. Yes,
> there are a handful of additional properties that MAY be used with it,
> but the marking function is the most important.
>
> When I say...
>
> {
> "@id": "http://example.org/foo",
> "@type": "as:Link"
> }
>
> What I'm saying is that doing a GET on "http://example.org/foo"
> returns something about that resource, which may not always be the
> case when working with an Activity Streams document (particularly one
> brought over from 1.0). So when I say something like:
What you're saying is that a HTTP URI is a HTTP URI. It doesn't actually
tell me what I can find there (I'm not sure what I've gained from
calling "http://example.org/foo" a link, except I've called a resource a
link, which is semantically wrong IMO)...
What are the exact semantics? e.g. is a URI allowed to have multiple
media types? If not, what happens when RDF unifies multiple Links
together (and what about the case of e.g. images on Twitter, where they
do content negotiation)
>
> {
> "@id": "http://example.org/foo",
> "@type": ["as:Link", "urn:example:Image"],
> "mediaType": "image/jpeg"
> }
>
> Yes, it really is both a "as:Link" and a "urn:example:Image".
>
> On Mon, Nov 3, 2014 at 3:45 PM, Owen Shepherd<owen.shepherd@e43.eu> wrote:
> [snipp
>> 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
>>
>
> Owen's argument on this is what convinced me to put as:Link back in
> and model it the way that I have. Take the following three cases:
>
> A. {
> "@type": "as:Link",
> "@id": "http://example.org/foo",
> "displayName": "A Link",
> "mediaType": "text/html"
> }
>
> B. {
> "@type": "urn:example:types:post",
> "@id": "urn:example:posts:123",
> "displayName": "A Post",
> "content": "A simple note"
> }
>
> C. {
> "@type": ["urn:example:types:post", "as:Link"],
> "@id": "http://example.org/foo",
> "displayName": "A Post",
> "content": "A simple note",
> "mediaType": "text/html"
> }
>
> A is just a Link. There is no other type information provided. The @id
> specifies a URL that can be dereferenced. The Link has a displayName
> and mediaType that identifies the MIME content type that can be
> expected when dereferencing.
(What if the target does content negotiation? Prefer to imply its a
content type you should be able to request from the URI)
> B is just an Object. In this case, the @id happens to not be dereferenceable.
I already noticed that. Its' URI isn't a type I know how to dereference.
I didn't need the absence of as:Link to tell me
> C is both a Link and an Object. The only real difference in this case
> is that @id happens to be dereferenceable.
For what? I presume text/html? Surely that should be an url?
Where do I find the application/activitystreams+json document for the
object? THAT is what @id defaulted to meaning, I thought (with link
rel=self or whatever the new alternative is being for the case where
your @id is non-dereferencable) ?
Surely a text/html document should be pointed to by url?
We are overloading the meaning of @id here
>> [snip]
>> 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?
>
> It does not need to be complicated:
>
> {
> "@type": ["urn:example:Video", "as:Link"],
> "@id": "https://yourtube.example/as78678j",
> "mediaType": "text/html",
> "title": "This is a funny video",
> "author": {
> "@id": "urn:example:person:sally",
> "displayName": "Sally",
> "image": {
> "@type": "as:Link",
> "@id": "http://example.org/img/sally.jpg",
> "displayName": "A picture of Sally",
> "mediaType": "image/jpeg"
> }
> },
> "url": [
> {
> "@type": "as:Link",
> "@id": "https://yourtube.example/as78678j.mpg",
> "mediaType": "video/mp4"
> },
> {
> "@type": "as:Link",
> "@id": "https://yourtube.example/as78678j.mkv",
> "mediaType": "video/mkv"
> }
> ],
> "image": "https://yourtube.example/as78678j.jpeg"
> }
>
> When processed through, the normalized version becomes:
>
> <http://example.org/img/sally.jpg> <as:displayName> "A picture of Sally" .
> <http://example.org/img/sally.jpg> <as:mediaType> "image/jpeg" .
> <http://example.org/img/sally.jpg> <rdf:type> <as:Link> .
> <https://yourtube.example/as78678j.mkv> <as:mediaType> "video/mkv" .
> <https://yourtube.example/as78678j.mkv> <rdf:type> <as:Link> .
> <https://yourtube.example/as78678j.mpg> <as:mediaType> "video/mp4" .
> <https://yourtube.example/as78678j.mpg> <rdf:type> <as:Link> .
> <https://yourtube.example/as78678j> <as:author> <urn:example:person:sally> .
> <https://yourtube.example/as78678j> <as:image>
> <https://yourtube.example/as78678j.jpeg> .
> <https://yourtube.example/as78678j> <as:mediaType> "text/html" .
> <https://yourtube.example/as78678j> <as:title> "This is a funny video" .
> <https://yourtube.example/as78678j> <as:url>
> <https://yourtube.example/as78678j.mkv> .
> <https://yourtube.example/as78678j> <as:url>
> <https://yourtube.example/as78678j.mpg> .
> <https://yourtube.example/as78678j> <rdf:type> <as:Link> .
> <https://yourtube.example/as78678j> <rdf:type> <urn:example:Video> .
> <urn:example:person:sally> <as:displayName> "Sally" .
> <urn:example:person:sally> <as:image> <http://example.org/img/sally.jpg> .
>
> Which just works.
>
> - James
-1. This is horrible. as:Link as defined is meaningless. It doesn't do
the job of AS1 MediaLinks, it does some horrible hybrid job.
as:Link is just noise here. It isn't telling me anything.
>> * 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".
> Owen Shepherd <mailto:owen.shepherd@e43.eu>
> 03 November 2014 23:45
>
>
> 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".
> ☮ elf Pavlik ☮ <mailto:perpetual-tripper@wwelves.org>
> 03 November 2014 18:17
> On 11/03/2014 06:50 PM, James M Snell wrote:
>> Yes we do. as:Link serves two purposes:
>>
>> 1. As a marker class used to indicate that the @id can be dereferenced; and
> Sounds like exactly the same aim as hydra:Link
> http://www.hydra-cg.com/spec/latest/core/#adding-affordances-to-representations
>
> I hope we can avoid defining exactly the same concept in two different
> specifications!
>
>> 2. As the value for properties like "image", "icon" and "url" which
>> may need additional metadata specified but do not need to be
>> represented as complete objects. (they play essentially the same role
>> as the MediaLink in AS 1.0).
> 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.
>
> James M Snell <mailto:jasnell@gmail.com>
> 03 November 2014 17:50
> Yes we do. as:Link serves two purposes:
>
> 1. As a marker class used to indicate that the @id can be
> dereferenced; and
>
> 2. As the value for properties like "image", "icon" and "url" which
> may need additional metadata specified but do not need to be
> represented as complete objects. (they play essentially the same role
> as the MediaLink in AS 1.0).
>
> I'm definitely -1 on removing as:Link.
>
> - James
>
> On Mon, Nov 3, 2014 at 9:36 AM, ☮ elf Pavlik ☮
>
> ☮ elf Pavlik ☮ <mailto:perpetual-tripper@wwelves.org>
> 03 November 2014 17:36
> +1
>
> in this case, do we have any other reason to keep as:Link?
>
> IMO JSON-LD embedding provides us with all we need to include statements
> about objects used as property values
>
> http://www.w3.org/TR/json-ld/#embedding
>
--
Sent using Postbox:
http://www.getpostbox.com
Received on Tuesday, 4 November 2014 18:57:46 UTC