Re: Issue-14: as:Link complexity

Consider this thought experiment: Take the following, process it down
to N-QUADS, then convert it back to JSON-LD:

{
  "items": [
    {
      "@context": {"@language": "en"},
      "@type": "Note",
      "displayName": "A Simple Note",
      "content": "This is a simple note",
      "image": {
        "@id": "http://example.org/img1.png",
        "displayName": "A Simple Caption"
      }
    },
    {
      "@context": {"@language": "sp"},
      "@type": "Note",
      "displayName": "Una nota simple",
      "content": "Esta es una simple nota",
      "image": {
        "@id": "http://example.org/img1.png",
        "displayName": "Un subtítulo sencilla"
      }
    }
  ]
}

_:b0 as:items _:b1 .
_:b0 as:items _:b2 .
_:b1 a as:Note .
_:b1 as:displayName "A Simple Note"@en .
_:b1 as:content "This is a simple note"@en .
_:b1 as:image <http://example.org/img1.png> .
_:b2 a as:Note .
_:b2 as:displayName "Una nota simple"@sp .
_:b2 as:content "Esta es una simple nota"@sp .
_:b2 as:image <http://example.org/img1.png> .
<http://example.org/img1.png> displayName "A Simple Caption"@en .
<http://example.org/img1.png> displayName "Un subtítulo sencilla" .

Serializing back into JSON-LD yields...

{
  "items": [
    {
      "@context": {"@language": "en"},
      "@type": "Note",
      "displayName": "A Simple Note",
      "content": "This is a simple note",
      "image": {
        "@id": "http://example.org/img1.png",
        "displayNameMap": {
          "en": "A Simple Caption",
          "sp": "Un subtítulo sencilla"
        }
      }
    },
    {
      "@context": {"@language": "sp"},
      "@type": "Note",
      "displayName": "Una nota simple",
      "content": "Esta es una simple nota",
      "image": {
        "@id": "http://example.org/img1.png",
        "displayNameMap": {
          "en": "A Simple Caption",
          "sp": "Un subtítulo sencilla"
        }
      }
    }
  ]
}

Which is clearly not what was intended. It's a simple and somewhat
contrived example but it illustrates the point that when a single
Activity Streams document includes aggregated content, relying solely
on JSON-LD embedding can lead to unexpected and often incorrect
results. Use of as:Link resolves these kinds of issues. Is it perfect?
No. Is it useful. Yes.  Can the examples in the spec be improved?
Absolutely. But as I've said before, I'm absolutely -1 on removing
as:Link.

- James

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 Monday, 20 April 2015 23:25:42 UTC