activitystreams
activitystreams copied to clipboard
`relationship` in JSON-LD context document should use `@type: @vocab`
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.
"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: https://github.com/w3c/activitystreams/issues/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.
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
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.
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).
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"
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.