Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
trwnh opened this issue Apr 27, 2024 · 6 comments
Open

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

trwnh opened this issue Apr 27, 2024 · 6 comments
Assignees
@evanp
Labels
Needs primer page Need to add a page at https://www.w3.org/wiki/Activity_Streams/Primer on this topic Next version Things that should probably be resolved in a next version of AS2

Comments

@trwnh
Copy link

trwnh commented Apr 27, 2024

Continuing from #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 w3c/activitypub#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.
@steve-bate
Copy link 

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

I like the idea in general, but weren't these terms dropped from the AS2 Recommendation a long time ago (and just not cleaned up in the context)?

See also: #406 (and related)

If so, it seems like @id may still be the best choice for as:relationship. Of course, as:Public is still an issue.

@trwnh
Copy link
Author

trwnh commented Apr 29, 2024 •
edited
Loading

type:vocab would still be best, to allow compaction of vocab terms used as the value of relationship, for example defining acquaintanceOf: http://purl...acquaintanceOf in your own context

@trwnh
Copy link
Author

trwnh commented Apr 29, 2024

i don't particularly mind either way if the four terms are removed from context document or not, but they indicate the intent for compacting values as vocab terms.

@steve-bate
Copy link

i don't particularly mind either way if the four terms are removed from context document or not, but they indicate the intent for compacting values as vocab terms.

Maybe... for compacting AS2 normative values. I think that compacting extension relationship predicate IRIs, like in your example, could lead to issues with plain JSON processing. Unlike with AS2 terms, there's no requirement to prevent plain JSON clashes of compacted extension predicates (e.g., your:FriendOf and my:FriendOf that may compact to "FriendOf" and may expand to either IRI, depending on the context ordering). Full IRIs seem safer for the extension scenario. (By "extension", I mean using non-as terms, not extending the as vocabulary).

@trwnh
Copy link
Author

trwnh commented Apr 29, 2024

there's no requirement to prevent plain JSON clashes of compacted extension predicates (e.g., your:FriendOf and my:FriendOf that may compact to "FriendOf" and may expand to either IRI, depending on the context ordering). Full IRIs seem safer for the extension scenario.

this just makes me think that this is why we need "best practices for extensibility" as in fep-e229 -- particularly the guidance to consider compacting ONLY against as2 (to generate consistent output for ld-unaware plain json consumers), or otherwise mandating that consumers MUST use the same context as you (which is more fragile)

for an ld-aware consumer supplying their own context, use of as:relationship is currently "bugged"

@evanp
Copy link
Collaborator

evanp commented May 1, 2024

In discussion in issue triage, @trwnh explained that we can only use unprefixed or compacted terms if the relationship property has @type: @vocab.

However, it is technically a breaking change from the current context document, although the breaking condition (you're using "rel:isInfluencedBy" as a literal string, and don't want it expanded) seems pretty rare and unusual.

I suggest that we mark this as "Next Version", document the fact that you can't currently use bare or compacted terms in relationship, and upgrade it in a future version of AS2.

@evanp evanp added Next version Things that should probably be resolved in a next version of AS2 Needs primer page Need to add a page at https://www.w3.org/wiki/Activity_Streams/Primer on this topic labels May 1, 2024
@evanp evanp self-assigned this May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@evanp evanp

Labels
Needs primer page Need to add a page at https://www.w3.org/wiki/Activity_Streams/Primer on this topic Next version Things that should probably be resolved in a next version of AS2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@evanp @steve-bate @trwnh