Re: Issue-14: as:Link complexity

-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!
> >>
> >
> >
>
>
>