Extending the Relationship type

Is it a good idea to extend the standard AS2 type Relationship, i.e. define a new type that is a subtype/subclass of it?

Relationship is kind of like RDF statement reification, so in a sense, you could just always use Relationship itself for all relationships, and detect the type of relationship using the relationship property, just like you detect object types using the type property.

Hmm but could there be benefits to extending the Relationship type?

  • Have properties whose domain or range is the custom extended type
  • Make it very clear right in the type that this is a specific kind of relationship
  • Allow the custom extended type to be used with multiple properties, possibly even allowing any of their potential subproperties. And under the open world assumption etc. there can be flexibility there, and using a custom extended type would allow to recognize all those properties under 1 well known title.

If extending Relationship with a custom type, should we still set the type of relationship objects to e.g. ["Relationship", "CustomType"] to allow generic AP implementations to recognize that it’s a relationship type, even without knowing what CustomType is?

Can you provide an example on how to use this?

Suppose you have a relationship called “ticket dependency”. It expresses that ticket X depends on ticket Y (in the sense of issue tracking, e.g. “Make a release of the project” could depend on “Write installation instructions”). Using a new TicketDependency type that would be a subtype of Relationship, it could look like this:

    "@context": [
    "type": ["Relationship", "TicketDependency"],
    "id": "https://example.dev/ticket-deps/2342593",
    "attributedTo": "https://example.dev/alice",
    "summary": "Alice's ticket depends on Bob's ticket",
    "published": "2019-07-11T12:34:56Z",
    "subject": "https://example.dev/alice/myproj/issues/42",
    "relationship": "dependsOn",
    "object": "https://dev.community/bob/coolproj/issues/85"
1 Like

What is the reason for having the custom TicketDependency type at all btw? If you need custom attributes, those can be added without having to understand a whole new type - which would be the best way to ensure compatibility with generic AP servers.

@jaywink, I listed above the potential advantages. The only cost is that type is set to ["Relationship", "TicketDependency"] instead of "Relationship". IIRC, correct me if I’m wrong, there are no standard side effects for Relationship objects (and the side effect for Creating a TicketDependency is more than standard generic stuff), so as long as generic AP servers can just grab the summary of the TicketDependency, or see that one of its types is Relationship and treat it as such, we don’t lose anything.

I think it’s easier to start with custom type and later switch back to standard, than start with standard and introduce potential ambiguity about processing Relationship objects.

  • I’d love to hear thoughts from people using Relationship objects in their projects
  • How about I use TicketDependency for now, and before the stable release of the spec, review this decision and switch to plain Relationship if there’s nothing to lose by doing that? Could even implement and test-drive both options and see how it goes :slight_smile:

I do like trying to keep things as simple as possible myself, which is why I was wondering why not just keep to the standard type and have extra attributes if needed - it seems the most flexible solution all concerned :thinking:

I think there’s a challenge about ActivityPub’s generality: One thing can have different meanings in different contexts, and each meaning may require different behavior. I like to keep things simple too, but I want to be sure they really are: Keeping the vocabulary simple may have a cost: Making the behavior complicated.

But you know what? Maybe you’re right and there’s nothing complicated there that I may be imagining. I want to examine in more detail :slight_smile:

Assume for now that the creation of ticket dependencies happens like this:

  • User sends an Offer whose object is a Relationship, in C2S to their homeserver
  • Homeserver delivers it in S2S
  • Destination server receives, suppose it accepts the offer, locally creates the actual ticket dependency in its DB, and authors and delivers an Accept activity

Assuming generic AP servers are smart about displaying useful summaries of Relationship objects, the difference that it would make to use a plain Relationship:

  • Need to recognize that it’s a ticket dependency using the relationship property
  • Can’t have properties whose RDF domain or range is TicketDependency because there will be no such type

Hmmmmmmmmmmmmmmmmmm fine, I’ll give plain Relationship a chance :slight_smile: as long as processing keeps being simple.