as:Link from Linked Data perspective + comparing with hydra:Link

[elf-pavlik]

This issue comes from observation I made on mailing list http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0143.html

I see it also relevant to hydra:Link and hope that @lanthaler could support us in clarifying it http://www.hydra-cg.com/spec/latest/core/#adding-affordances-to-representations

Looking at examples from @jasnell original email http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0139.html

  "actor": {
    "@type": "urn:example:objectType:person",
    "displayName": "Sally"
  }

  "actor": {
    "@type": "http://activitystrea.ms/2.0/Link",
    "@id": "http://example.org/profiles/sally",
    "mediaType": "text.html"
  }

As I understand it

• first states that actor has @type urn:example:objectType:person
• second states that actor has @type as:Link

Next example which 'mixes' first two

  "actor": [
    {
      "@type": "urn:example:objectType:person",
      "displayName": "Sally"
    },
    {
      "@type": "http://activitystrea.ms/2.0/Link",
      "@id": "http://example.org/profiles/sally",
      "mediaType": "text.html"
    }
  ]

I could interpret it as: two actors, first one (blank node!) has type urn:example:objectType:person second one (node identified by IRI) has type as:Link

I get quite confused if I try to 'mix' it differently, similar as in one of my emails on that thread: http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0141.html

 "actor": {
   "@type": ["urn:example:objectType:person", "http://activitystrea.ms/2.0/Link"]
   "displayName": "Sally",
   "@id": "http://example.org/profiles/sally",
   "mediaType": "text.html"
}

which for me states that person name Sally has mediaType "text.html"

I must admit that I feel confused about such 'mixing' of types like schema:Person and as:Link.

While hydra:Link gets defined as:

{
  "@id": "hydra:Link",
  "@type": "hydra:Class",
  "comment": "The class of properties representing links.",
  "label": "Link",
  "subClassOf": [
    "hydra:Resource",
    "rdf:Property"
  ],
  "status": "testing"
}

as:Link has definition:

{
  "@id": "as:Link",
  "@type": "owl:Class",
  "rdfs:subClassOf": "owl:Thing"
}

I have impression that defining hydra:Link as subClassOf rdf:Property and using it this way might make some significant difference... Possibly also relevant to my email about using object keys in JSON-LD

[lanthaler]

hydra:Link is the class representing the set of properties that are links. As you probably know, in RDF IRIs are identifiers and don't necessarily have to be dereferenceable. hydra:Link along with hydra:Resource makes it understandable to a machine which of those identifiers are also locators. Currently, the best you can do is to blindly try to dereference all identifiers and check which do reference and which don't.

The examples you posted are OK from my perspective but the type as:Link is misleading IMO. A link is the arc that connects two resources. It is not the target resource. Thus, I would propose to replace as:Link with something like as:WebResource or hydra:Resource.

[jasnell]

Defining as:Link as being disjoint from as:Object ought to work also. In practice, I think AS ought to include a normative requirement that implementers SHOULD NOT specify multiple @type values, and that if they do, those MUST NOT overlap as:Link and as:Object.

[elf-pavlik]

@jasnell what do you think about Markus' comment

the type as:Link is misleading IMO. A link is the arc that connects two resources. It is not the target resource. Thus, I would propose to replace as:Link with something like as:WebResource or hydra:Resource.

As I understand RDF conceptual model, a directed labeled graph, where nodes (object, subject) and edges (predicates) have rather different purpose. I do have impression that as:Link tries to turn edge into a node, or predicate into object, subject. I see later happening in RDFS and OWL but currently I don't think AS2.0 would benefit from using similar patterns.

[jasnell]

as:Link is a node that describes a reference to another resource. It is not intended to be an edge on it's own.

{
  "@type": "urn:example:person:joe",
  "icon": {
    "@type": "http://activitystrea.ms/2.0/Link",
    "@id": "http://example.org/foo.png",
    "height": 16, "width": 16
  }
}

Here, "http://activitystrea.ms/2.0/icon" is the edge.

[elf-pavlik]

do you aim at something similar to Qualified Relation Pattern also used in schema:Role ?http://blog.schema.org/2014/06/introducing-role.html

[lanthaler]

Right @jasnell.. but in your example you describe the resource foo.png, not the link to it. Or is it the link’s height and width?

[jasnell]

Yes, it's essentially a qualified relation. The difference, however, is that in as:Link, the @id is overloaded to provide both the @id of the node and the target of the Link.

[elf-pavlik]

@jasnell I really don't feel convinced about as:link, and instead lean more toward using appropriate rdf:predicate plus @type on an rdf:object than as @lanthaler suggested you can use Resource type eg. hydra:Resource to get all the other properties you need to describe that web resource (mediaType, width, height etc.)

I hope we won't cross the streams :wink: here by messing with HTTPRange-14

{
  "@id": "https://wwelves.org/perpetual-tripper",
  "@type": ["schema:Person", "hydra:Resource"] ,
  "schema:name": "elf Pavlik",
  "schema:nationality": "ex:NotApplicable",
  "as:mediaType": "text/html"
}

but overloaded @id ATM sounds even more scary to me :smile:

[jasnell]

With the commit, Link has been reworked a bit to closer align with how hydra:Link works. Clarifications have been added to the spec.

[elf-pavlik]

@jasnell I still find it pretty confusing that you use @type as:Link and ex:ImageResource on the same object:

"image": {
          "@id": "http://example.org/martin/image",
          "@type": [
            "http://activitystrea.ms/2.0/Link",
            "http://example.org/ImageResource"
          ],
          "mediaType": "image/jpeg",
          "width": 250,
          "height": 250
        }

Could you please point me to some more information about what you refereed to as overloaded @id in:

Yes, it's essentially a qualified relation. The difference, however, is that in as:Link, the @id is overloaded to provide both the @id of the node and the target of the Link.

I also would like to make Pull Request which references this ISSUE inline to the spec, similar as we see some of the open issues in Hydra Core spec. Should I make commit on top of gh-pages branch?

I noticed such recommendation in http://www.w3.org/2014/Process-20140801/#working-draft

A Public Working Draft is published on the W3C's Technical Reports page [TR] for review, and for simple historical reference. For all Public Working Drafts a Working Group

• SHOULD document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
• MAY request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.

[akuckartz]

@elf-pavlik

I also would like to make Pull Request which references this ISSUE inline to the spec, similar as we see some of the open issues in Hydra Core spec.

I suggest to create a new GitHub issue for that ("Reference issues inline in the spec").

[elf-pavlik]

looking at properties current draft recommends to use with as:Link rel | mediaType | language | displayName | title | hreflang

we have language and displayName also suggested for as:Object which leaves us with rel | mediaType | title | hreflang

i think predicate for which we currently use instances of as:Link as values already takes care of what one might want to use rel for, so if we need "rel": "preview" we could for example define as:previewImage rdfs:subPropertyOf as:image or maybe

{ "@context": { "preview": "http://www.iana.org/assignments/link-relations/link-relations.xhtml#preview", ... } }

if target object has certain language we could use as:language directly on that embedded object (unless we resolve #21 differently)

when it comes to mediaType, just like with height, width etc. i looks like an property of an object we want to reference.

{
  "@type": "http://schema.org/Person",
  "icon": {
    "@type": "http://schema.org/ImageObject",
    "@id": "http://example.org/foo.png",
    "height": 160,
    "width": 160,
    "mediaType": ["image/png", "image/svg+xml"]
  }
}

@jasnell could you provide some example where you see need to use as:Link and qualified relationship instead of simply using precise predicate and properties of embedded object?

version of examples from as:Link section of current draft but without using as:Link http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#link

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

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "urn:example:types:application",
  "image": "http://example.org/foo.jpg",
  "previewImage": {
     "@id": "http://example.org/screens/1.jpg",
     "@type": "urn:example:image",
     "mediaType": "image/jpeg"
   }
}

[elf-pavlik]

relevant conversation https://github.com/mnot/I-D/issues/39 with contributions from @dret and @jasnell

[dret]

what about using established terminology from web standards and use "rel" to identify a link's relation, and "target" to identify a link's target? then we could also be compliant with RFC 5988 and use registered relations as their registered values, instead of creating a parallel universe where registered relations are identified by URIs which are not really their identifiers per RFC 5988.

[elf-pavlik]

I also don't understand why as:to, as:cc, as:bto, as:bcc specify Value: Link (while most other properties specify Value: Object | Link) , does it mean that I shouldn't do:

{
  ...
  "to": {
    "@id": "https://wwelves.org/perpetual-tripper",
    "@type": "http://schema.org/Person",
    "displayName": "elf Pavlik"
  }
}

?

[erincandescent]

I have no idea why as:to/cc/bcc would specify Link as their property type (legacy from an old version where Link was a superclasss of Object?). AS1 used an array of Object there.

Part of this is that we need to not use @id to represent the URI of the link, because under JSON-LD processing this will cause all Links to the same resource to be "blobbed together". (Actually, it complicates things in other areas to: is a given URL an abbreviated Object or Link?)

I'm of the opinion that the Object/Link unification is a failed experiment. If we are to retain link relations in AS2, then we should probably revert to a model closer to AS1's, where they're a "separate axis" under a "links" member.

If we do so, then I suggest that the "links" member should be an array of "Link" which should have members aligned with JRD links (See http://tools.ietf.org/html/rfc7033#section-4.4.4 )

I say this for a few reasons:

• The "links" property, as is in AS1, is incompatible with the JSON-LD processing model
• The JRD model is broadly sensible
• We shouldn't needlessly reinvent the wheel.
• It avoids a case of "single value or array". These are useful (they make generating AS2 easier, they make the document slightly more concise), but we have to remember that people will end up implementing things, accidentally or through laziness which assume only a single value for a given property. Therefore, we should express care when adding such properties.

[jasnell]

to/bto/cc/bcc should be Link or Object. That's a spec bug. Will fix.

[elf-pavlik]

Relevant conversation on Hydra CG list proposing removal of hydra:Resource (similar in definition to as:Link) and hydra:Class http://lists.w3.org/Archives/Public/public-hydra/2015Jan/0022.html One can find there various comments about how to assume (or not) that we can dereference something. @gkellogg mentioned that in scenarios he works with hydra:Link ( defined differently then in AS, as rdfs:subClassOf rdf:Property) http://www.hydra-cg.com/spec/latest/core/#hydra:Link

[elf-pavlik]

discussion continues in Hydra CG https://github.com/HydraCG/Specifications/issues/91 which also links to accompanying thread on mailing list

[elf-pavlik]

I created issue in Social WG tracker for as:Link https://www.w3.org/Social/track/issues/14

[jasnell]

WG decision to keep as:Link as defined.