w3c / w3c/activitystreams

`relationship` in JSON-LD context document should use `@type: @vocab`

Open
#593 7 comments 0 reactions 1 assignee View on GitHub

@evanp is already working on this.

Since May 1, 2024.

Next version
Dominant language
HTML
Stars
313
Forks
70
PR merge metrics
No merged PRs in 30d

Description

Continuing from https://github.com/w3c/activitystreams/issues/289

Summary

We have the following term definitions in the context document:

{
  "@context": {
    "Relationship": "as:Relationship",
    "IsFollowing": "as:IsFollowing",
    "IsFollowedBy": "as:IsFollowedBy",
    "IsContact": "as:IsContact",
    "IsMember": "as:IsMember",
    "subject": {
      "@id": "as:subject",
      "@type": "@id"
    },
    "relationship": {
      "@id": "as:relationship",
      "@type": "@id"
    },
    "object": {
      "@id": "as:object",
      "@type": "@id"
    }
  }
}

These are used with modeling Relationship entities as described in https://www.w3.org/TR/activitystreams-vocabulary/#connections

Problem

The normative text of AS2-Vocab Section 5.2 reads:

The relationship property specifies the kind of relationship that exists between the two individuals identified by the subject and object properties. Used together, these three properties form what is commonly known as a " reified statement" where subject identifies the subject, relationship identifies the predicate, and object identifies the object.

So, if relationship identifies the predicate, then shouldn't it have its own URI just like any other RDF predicate?

Proposal

Luckily there's a mechanism in JSON-LD to express just this, and it's @type: @vocab.

{
  "@context": {
    "relationship": {
      "@id": "as:relationship",
      "@type": "@vocab"
    }
  }
}

From JSON-LD 1.1, Section 5.2.1 "Shortening IRIs": https://www.w3.org/TR/json-ld11/#shortening-iris

The vocabulary mapping can be used to shorten IRIs that may be vocabulary relative by removing the IRI prefix that matches the vocabulary mapping. This is done whenever an IRI is determined to be vocabulary relative, i.e., used as a property, or a value of @type, or as the value of a term described as "@type": "@vocab".

Section 4.2.3 "Type Coercion": https://www.w3.org/TR/json-ld11/#type-coercion (emphasis mine)

It is important to note that terms are only used in expansion for vocabulary-relative positions [...] Values of @id are considered to be document-relative, and do not use term definitions for expansion.

So basically, @type: @id will not work because it is not vocabulary-relative. But @type: @vocab will work, because it defines the property's value(s) as vocabulary-relative.

A similar issue occurs in ActivityPub with Public being defined as as:Public as described in https://github.com/w3c/activitypub/issues/404 -- in that issue, we can see that the term definition of Public actually does nothing, because the properties to/cc/bto/bcc/audience are all defined as @type: @id, which is not vocabulary-relative, and thus will not expand any IRIs according to term definitions.

Actionable items:

Change the term definition for relationship so that its @type is @vocab instead of @id

This is probably less contentious than redefining to/cc/bto/bcc/audience, because those are more properly defined in terms of @id, since their values are expected to be graph nodes. It makes no difference for expansion, since they will both expand to {"@id": "value"}, but it does make a difference for compaction, which matters more for AS2 because of the requirement to be consistent with the compacted form. It's also less contentious because relationship is probably far less commonly used than to/cc/bto/bcc/audience.

But yeah, in summary, if nothing is done, then the following term definitions are currently doing nothing:

    "IsFollowing": "as:IsFollowing",
    "IsFollowedBy": "as:IsFollowedBy",
    "IsContact": "as:IsContact",
    "IsMember": "as:IsMember",

I see this as a bug in the JSON-LD context document, not as a normative spec change.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.