Re: Issue-14: as:Link complexity

Yes, as:Link is still needed. See the example I gave previously. In
many cases, the intent of the publisher is to describe properties of
the *reference* and not the *object*. Publishers are given the choice
of which to use. I'm absolutely -1 on removing as:Link.

On Tue, Apr 21, 2015 at 9:22 AM, Henry Story
<henry.story@co-operating.systems> wrote:
>
>> On 21 Apr 2015, at 17:42, James M Snell <jasnell@gmail.com> wrote:
>>
>> https://github.com/jasnell/w3c-socialwg-activitystreams/pull/100
>
> Is the Link type still needed?
>
> Currently the Turtle is:
>
> <http://example.org/application/123> a as:Application ;
>     as:displayName "My Application" ;
>     as:image [   a  as:Link ;
>                  as:href <http://example.org/application/123.png> ;
>                  as:mediaType "image/png"
>               ] .
>
> Why not instead do the simple thing, namely
>
> <http://example.org/application/123> a as:Application ;
>     as:displayName "My Application" ;
>     as:image <http://example.org/application/123.png> .
>
> <http://example.org/application/123.png> as:mediaType "image/png" .
>
>
>
>>
>> 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 16:24:49 UTC