Re: Issue-14: as:Link complexity

https://github.com/jasnell/w3c-socialwg-activitystreams/pull/100

On Tue, Apr 21, 2015 at 8:14 AM, James M Snell <jasnell@gmail.com> wrote:
> Perhaps the best approach to resolving this would be to remove the
> "rel" property entirely so that there's no conflict. If someone wants
> to go about defining a JSON context for Link Relations (e.g.
> http://linkrels.mybluemix.net/links) then one can easily use that as
> an extension and much of the "weirdness" goes away.
>
> On Sun, Apr 19, 2015 at 9:39 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
>>
>> 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

Received on Tuesday, 21 April 2015 15:43:28 UTC