Re: Issue-14: as:Link complexity

On 04/19/2015 06:39 PM, Robert Sanderson 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"
>   }
> }

I meant it exactly this way, just made typo by not deleting 'href'!
Thought "iana" prefix URI might need to use something different, I feel
bit low on optimism here because of silence in
https://github.com/mnot/I-D/issues/39

> 
> 
> * 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"
>   }
> }
+1


> 
> (To arbitrarily pick a class for the resource)
> 
> 
> 
> Thanks!
Thanks Rob!

I wonder what do you think about this example in current working draft
http://tinyurl.com/ku2j9eg

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "Application",
  "@id": "http://example.org/application/123",
  "displayName": "My Application",
  "image": [
    "http://example.org/application/abc.gif",
    {
      "@type": "Link",
      "href": "http://example.org/application/123.png",
      "mediaType": "image/png",
      "rel": "canonical"
    }
  ]
}

*An image is canonical for an application?*

For me this "canonical" use looks incorrect here, I guess it supposed to say

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "Application",
  "@id": "http://example.org/application/123",
  "displayName": "My Application",
  "image": {
    "@id": "http://example.org/application/abc.gif",
    "canonical": {
      "@id": "http://example.org/application/123.png",
      "mediaType": "image/png",
      "rel": "canonical"
    }
  }
}

While it seems to say

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "Application",
  "@id": "http://example.org/application/123",
  "displayName": "My Application",
  "image": "@id": "http://example.org/application/abc.gif",
  "canonical": {
    "@id": "http://example.org/application/123.png",
    "mediaType": "image/png",
    "rel": "canonical"
  }
}

If it turns out that current draft of a spec actually uses incorrect
subject in this statement. IMO it gives pretty strong example that
as:Link can contribute to the confusion about underlying data model.



I also consider fact that current draft introduces *as:next* and
*as:prev* as an interesting hint:
* http://www.w3.org/TR/activitystreams-vocabulary/#dfn-next
* http://www.w3.org/TR/activitystreams-vocabulary/#dfn-prev

they get used as RDF predicates (properties)

"next": {
  "@type": "Link",
  "displayName": "Next Page",
  "href": "http://example.org/collection"
}

"prev": {
  "@type": "Link",
  "displayName": "Previous Page",
  "href": "http://example.org/collection"
}

and NOT with *rel*, even that those two relations already exist in IANA
registry - (assuming existence of very generic property as:link):

"link": [
  {
    "@type": "Link",
    "displayName": "Next Page",
    "href": "http://example.org/collection",
    "rel": "next"
  }
]

"link": [
  {
    "@type": "Link",
    "displayName": "Previous Page",
    "href": "http://example.org/collection",
    "rel": "prev"
  }
]

having displayName definitions elsewhere for *first* and *last*
properties themselves as "First Page" and "Last Page"

{
  "@id": "next",
  "displayNameMap": { "en": "Next Page" }
}

{
  "@id": "prev",
  "displayNameMap": { "en": "Previous Page" }
}

we can again use simple

"next": "http://example.org/collection"

"prev": "http://example.org/collection"


and BTW, current usage of our unfortunate *rel* in examples gives
another hint about its significance:

* core: *1* (just in example for as:Link)
* vocab: *1* (just in example for itself - 'rel')

I really see us currently pretty far from marking this issue as resolved!

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

Received on Monday, 20 April 2015 22:26:20 UTC