Re: Issue-14: as:Link complexity

Some thoughts...

* It's strange (to me) to have the value of a key called "image" to be a
reified relationship rather than an image.

{
  "image": {
    "@id": "http://example.org/images/1",
    "@type": "as:Link",
    "rel": "thumbnail",
    "href": "http://example.org/images/1.jpg"
  }
}

If it the key was "related" or similar, that might make more sense?  But
then you'd need to trawl through all of the Link objects to find the
thumbnail.
Which is why using it in the simpler form proposed seems reasonable to me,
barring any other requirements.


* It's even simpler than Elf's example:

{
  "thumbnail": "http://example.org/images/1.jpg"
}

With the context:

{
  "@context": {
    "iana": "http://www.iana.org/assignments/relation/",
    "thumbnail": "iana:thumbnail"
  }
}


* What about the other parameters for link relations?  Do we expect to see
Links like:

{
  "image": {
    "@id": "http://example.org/images/1",
    "@type": "as:Link",
    "rel": "thumbnail",
    "href": "http://example.org/images/1.jpg",
    "type": "image/jpeg",
    "title": "Thumbnail Image",
    "media": "screen"
  }
}


This would still be more accurately represented as the simpler:

{
  "thumbnail": {
    "@id": "http://example.org/images/1.jpg",
    "@type": "schema:Image",
    "format": "image/jpeg",
    "label": "Thumbnail Image",
    "media": "screen"
  }
}

(To arbitrarily pick a class for the resource)



Thanks!

Rob


On Sun, Apr 19, 2015 at 9:15 AM, James M Snell <jasnell@gmail.com> wrote:

> -1. This was the path I originally proposed for Link relations but it
> quickly became apparent that it would become unmanageable.
> On Apr 19, 2015 9:10 AM, "☮ elf Pavlik ☮" <perpetual-tripper@wwelves.org>
> wrote:
>
>> On 04/19/2015 04:59 PM, Evan Prodromou wrote:
>> > Elf Pavlik,
>> Hi Evan,
>>
>> >
>> > I strenuously object to removing this element.
>> >
>> > The intent is to allow mapping IETF-style link-relations into Activity
>> > Streams. For AS1, pump.io at least uses the link elements quite a bit.
>> >
>> > http://www.iana.org/assignments/link-relations/link-relations.xhtml
>> >
>> > One thing I like is that you can map the same link relations into e.g.
>> > <a> or <meta> tags in HTML, Link: headers in HTTP, Webfinger, and in
>> > Activity Streams.
>> We can still use link relations by mapping them in JSON-LD context and
>> using as attributes on objects. Please take a look at this long and
>> confusing github issue
>> https://github.com/mnot/I-D/issues/39
>>
>> {
>>   ...,
>>   "image": {
>>     "@type": "Link",
>>     "rel": "thumbnail",
>>     "href": "http://example.com/image.jpeg"
>>   }
>> }
>>
>> becomes simple
>>
>> {
>>   ...,
>>   "thumbnail": "href": "http://example.com/image.jpeg"
>> }
>>
>> >
>> > As our social API develops, it's likely that these different sources of
>> > data will be used to discover structured information about a user or
>> > content object. For example, pump.io uses the "activity-inbox" and
>> > "activity-outbox" relation types to discover the activity streams inbox
>> > and outbox URLs for a user.
>> Did you register those relation types with IANA and/or microformats wiki
>> or you use full URIs?
>>
>>
>> Cheers!
>>
>> >
>> > Some link relations, like "self", are really useful for tracking down
>> > the source of an AS object so you can get more information.
>> >
>> > James, do you think we could use a different example than a linked image
>> > in the AS 2.0 doc so it's clearer what we're trying to do?
>> >
>> > -Evan
>> >
>> > On 2015-04-19 05:48 AM, ☮ elf Pavlik ☮ wrote:
>> >> On 04/13/2015 05:52 PM, James M Snell wrote:
>> >>> Issue-14 claims that as:Link adds to much complexity. Unfortunately,
>> >>> it doesn't explain why. Elf has brought this up in a few discussions
>> >>> but so far, he's the only one that seems to be raising objections on
>> >>> it. The argument against it is vague and seems to be purely academic
>> >>> and I recommend simply closing the issue unless there is clear
>> >>> consensus that the existing definition of as:Link is actually a
>> >>> problem *in practice*.
>> >> Hi James,
>> >>
>> >> I started pull request which includes first commits which remove
>> as:Link
>> >> from examples in core spec. We could discuss it there on concrete
>> >> examples why you see need for using it over conventional JSON-LD
>> >> embedding. It also has diagram illustrating on of the main issues I
>> find
>> >> with it.
>> >> https://github.com/jasnell/w3c-socialwg-activitystreams/pull/98
>> >>
>> >> Please notice that you and Evan didn't reply to various questions I
>> >> asked on a mailing list thread automatically created for ISSUE-14 the
>> >> tracker
>> >> *
>> https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0062.html
>> >> *
>> https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0202.html
>> >> *
>> https://lists.w3.org/Archives/Public/public-socialweb/2015Apr/0009.html
>> >>
>> >> We can have more concrete discussion once we get all examples from
>> specs
>> >> properly available in JSON-LD Playground. I will also continue drawing
>> >> diagrams for those examples so we can see better graphs we construct.
>> >> Some early diagrams I already shared in
>> >> * https://github.com/jasnell/w3c-socialwg-activitystreams/issues/99
>> >>
>> >> If we want to see some problem *in practice*, let's start adding to
>> test
>> >> suite, for each case in which whenever vocab allows both as:Object and
>> >> as:Link, we create tests for *both* possible variants. But if in every
>> >> case we can model particular data by using JSON-LD embedding, I really
>> >> don't see justification for introducing as:Link.
>> >> Pull request I started should either prove no need for as:Link or
>> >> identify clear cases when we *really need* to have such construct.
>> >>
>> >> Cheers!
>> >>
>> >
>> >
>>
>>
>>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305