Re: Issue-14: as:Link complexity - AtomOwl

I spent a lot of time thinking about Link relations 10 years ago when working on the Atom 
XML syntax ( RFC 4287 [1] ), which the Web Linking RFC 5988 refers to [2] .  Since Activity
Streams is meant to be compatible with Atom syntax, it may be interesting to see how else
one can model Link relations.

In developing the Atom Owl ontology  I tried to make sure I could use it to map Atom 
to RDF and back, whilst also producing as clean as possible RDF ( for which there is an
isomorphic mapping to json-ld ).

  http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#Link <http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#Link>


[[
Link Class - see §4.2.7 <http://www.atompub.org/rfc4287.html#rfc.section.4.2.7> of rfc 4287 spec. Note that the href, hreflang and lengtlength attributes of rfc 4287 have been moved to the content class and a content relation from the Link to a Content class has been made. The href is translated onto the :src relation of the Content class. A link is a reified relation between an entry an a content, for the purpose of adding some metadata such as a title. If it is a reified statement, it is a special type of such a statement, one that implies always the reified statement itself (see N3 rule) 
]]

So you’d have an Atom Entry with a Link relation like the following ( in Turtle )

:entry1 :link [ a :Link;
                :rel iana:alternate ;
                :to [ :src <http://example.org/2003/12/13/atom03 <http://example.org/2003/12/13/atom03>>; ]
              ] .


Since not everyone reads turtle, we can describe it in terms of a graph like
this



So we can already see the difference with the current activity streams modelling, 
( as I understand it by reading Elf’s comments [3] ) is that the relation from the entry 
to the  object is the link relation not the iana:alternate relation . Elf’s example is even
clearer. Instead of iana:alternate he uses as:image . Doing this makes it immediately 
clear that it is odd to think of as:image as relating a person to something as abstract 
as a link relation as Robert Sanderson pointed out.

What is interesting is that if you look at the above diagram and twist your mind a bit you
can make the following mapping betwen the relations used above and the rdf Reification 
vocabulary




namely:

• the inverse of awol:link is a subrelation of rdf:subject
• awol:rel is a subrelation of rdf:predicate
• awol:object is a subrelation of rdf:object

If you add to that a reasonable assumption that anyone making a link relation
statement in an atom xml file is asserting the truth of that Reification then if follows
from the above that

<entry> iana:alternate <document> .

which is the relation drawn in red in the second diagram.

Ie we can directly link the entry to the document via the iana:alternate relation or the as:image relation.
Both are two ways to say the same thing. The re-ificiation just gives you a way to add metadata on the
link relation itself. This could be useful if say you thought that the title was the title of the link, rather than the title of the object
of the relation. But I think that over the past 8 years it seems to have become clear that the title was not the title of the
reified link, but the title of the object of the link. (see RFC5988 on Web Linking §5.4 ).  As that has become clear
it means also that there is no need for the re-ification anymore ( which I only added to Atom-Owl out of prudence).
Elf is clearly correct in that the direct relation is a lot simpler than the re-ified one.


So I agree with Elf and Robert Sanderson that this part of AS2.0 could be modelled much more simply.
Given that I’d propose that AS2 link directly  to the document as shown above.

Henry
PS. Elf tells me that he has worked on reification in 
https://github.com/jasnell/w3c-socialwg-activitystreams/issues/99

[1] https://tools.ietf.org/html/rfc4287 <https://tools.ietf.org/html/rfc4287>
[2] https://tools.ietf.org/html/rfc5988 <https://tools.ietf.org/html/rfc5988>
[3] https://github.com/jasnell/w3c-socialwg-activitystreams/pull/98 <https://github.com/jasnell/w3c-socialwg-activitystreams/pull/98>
[4] http://www.w3.org/TR/rdf-schema/#ch_reificationvocab <http://www.w3.org/TR/rdf-schema/#ch_reificationvocab>


> On 19 Apr 2015, at 18:39, Robert Sanderson <azaroth42@gmail.com <mailto: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 <http://example.org/images/1>",
>     "@type": "as:Link",
>     "rel": "thumbnail",
>     "href": "http://example.org/images/1.jpg <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 <http://example.org/images/1.jpg>"
> }
> 
> With the context:
> 
> {
>   "@context": {
>     "iana": "http://www.iana.org/assignments/relation/ <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 <http://example.org/images/1>",
>     "@type": "as:Link",
>     "rel": "thumbnail",
>     "href": "http://example.org/images/1.jpg <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 <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 <mailto: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 <mailto: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 <http://pump.io/> at least uses the link elements quite a bit.
> >
> > http://www.iana.org/assignments/link-relations/link-relations.xhtml <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 <https://github.com/mnot/I-D/issues/39>
> 
> {
>   ...,
>   "image": {
>     "@type": "Link",
>     "rel": "thumbnail",
>     "href": "http://example.com/image.jpeg <http://example.com/image.jpeg>"
>   }
> }
> 
> becomes simple
> 
> {
>   ...,
>   "thumbnail": "href": "http://example.com/image.jpeg <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 <http://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 <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/0062.html>
> >> * https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0202.html <https://lists.w3.org/Archives/Public/public-socialweb/2015Mar/0202.html>
> >> * https://lists.w3.org/Archives/Public/public-socialweb/2015Apr/0009.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 <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/