Re: Issue-14: as:Link complexity

> On 21 Apr 2015, at 18:24, James M Snell <jasnell@gmail.com> wrote:
> 
> 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.

Sorry, what is reference here? Let me guess:

Option 1: You mean the URL. But the URL has no media type of "image/png" .
Option 2: You mean the content or the representation. In that case I would not call it a as:Link,
 but instead an as:Content as I put forward in Atom-OWL ontology

  http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#Content

But then a problem is that you are not really allowing content negotiation to play out correctly. For example if a server presents an image under 10 different mime types, it's much better to have 1 url and specify perhaps which mime types are available, rather than 10 urls, and then have the client have to decide.
In any case you can also do that indirectly like this


</application/123> a as:Application ;
   as:displayName "My Application" ;
   as:image </application/image> .

</application/image> iana:alternate </application/image.png>, <application/image.jpg> .
</application/image.png> as:mediaType "image/png" .
</application/image.jpeg> as:mediaType "image/jpeg" .

It then turns out that your as:Link is just a special case of the above, where you refuse to give a name
to the content negotiationed resource ( by making it a blank node ).

Now the advantage of working with content negotatiated resourceds are:

• that a client that wants the server to do the content negotation, just needs to follow the as:image relation, to create its html an insert the object of the triple in the <a href=$url > field. If the client wants to have more say in the selection of content it can then follow the iana:alternate relation to get a specific version. It is better to allow content negotiation to be done by the server in a standard way that the web has been built on. 
• It also makes it simpler for example to upload images, as this would allow a client by uploading one high resolution image to get all the other ones to come along with it through server generation. This also makes deletion, and alteration of resources easier as it then no longer needs to upload 10 different versions of the  image.


Henry 


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

Social Web Architect
http://bblfish.net/

Received on Tuesday, 21 April 2015 16:48:53 UTC