[TRACKING] FEP-5711: Inverse Properties for Collections #539

Open
opened 2025-03-24 22:10:36 +01:00 by helge · 4 comments
Member

The proposal has been received. Thank you!

This issue tracks discussions and updates to the proposal during the DRAFT period.

Please post links to relevant discussions as comments to this issue.

dateReceived: 2025-03-24

If no further actions are taken, the proposal may be set by the facilitators to WITHDRAWN on 2026-03-24 (in 1 year).

The [proposal](https://codeberg.org/fediverse/fep/src/branch/main/fep/5711/fep-5711.md) has been received. Thank you! This issue tracks discussions and updates to the proposal during the `DRAFT` period. Please post links to relevant discussions as comments to this issue. `dateReceived`: 2025-03-24 If no further actions are taken, the proposal may be set by the facilitators to `WITHDRAWN` on 2026-03-24 (in 1 year).
Author
Member
Discussions: https://codeberg.org/evanp/fep/issues
Contributor

@evanp I've been working on implementing FEP-5711 in Fedify and encountered a technical issue that should be addressed in the specification. The FEP references the context URL https://w3id.org/fep/5711 in examples, but this URL doesn't currently resolve to a valid JSON-LD context document. This causes JSON-LD processors to fail when trying to process documents that include this context.

This creates a significant barrier for implementation since JSON-LD processors throw errors when encountering the context URL in @context arrays. For now, implementations need to include the context definition in their preloaded contexts as a workaround, but it would be much better if the specification provided clear guidance on what the context should contain.

I think the FEP should either include the complete JSON-LD context definition in the specification document itself, or ensure that https://w3id.org/fep/5711 actually serves the context. Having the context definition in the spec would be particularly helpful for implementers to understand exactly how the 8 inverse properties should be defined.

Based on the FEP specification, here's what the JSON-LD context should look like:

{
  "@context": {
    "likesOf": {
      "@id": "https://w3id.org/fep/5711#likesOf",
      "@type": "@id"
    },
    "sharesOf": {
      "@id": "https://w3id.org/fep/5711#sharesOf",
      "@type": "@id"
    },
    "repliesOf": {
      "@id": "https://w3id.org/fep/5711#repliesOf",
      "@type": "@id"
    },
    "inboxOf": {
      "@id": "https://w3id.org/fep/5711#inboxOf",
      "@type": "@id"
    },
    "outboxOf": {
      "@id": "https://w3id.org/fep/5711#outboxOf",
      "@type": "@id"
    },
    "followersOf": {
      "@id": "https://w3id.org/fep/5711#followersOf",
      "@type": "@id"
    },
    "followingOf": {
      "@id": "https://w3id.org/fep/5711#followingOf",
      "@type": "@id"
    },
    "likedOf": {
      "@id": "https://w3id.org/fep/5711#likedOf",
      "@type": "@id"
    }
  }
}

All properties use "@type": "@id" since they are functional properties that reference objects or actors. Would it be possible to either add this context definition to the FEP document or set up the w3id.org redirect to serve the actual context? This would greatly help implementers and improve adoption of FEP-5711.

@evanp I've been working on [implementing FEP-5711 in Fedify](https://github.com/fedify-dev/fedify/issues/373) and encountered a technical issue that should be addressed in the specification. The FEP references the context URL `https://w3id.org/fep/5711` in examples, but this URL doesn't currently resolve to a valid JSON-LD context document. This causes JSON-LD processors to fail when trying to process documents that include this context. This creates a significant barrier for implementation since JSON-LD processors throw errors when encountering the context URL in `@context` arrays. For now, implementations need to include the context definition in their preloaded contexts as a workaround, but it would be much better if the specification provided clear guidance on what the context should contain. I think the FEP should either include the complete JSON-LD context definition in the specification document itself, or ensure that `https://w3id.org/fep/5711` actually serves the context. Having the context definition in the spec would be particularly helpful for implementers to understand exactly how the 8 inverse properties should be defined. Based on the FEP specification, here's what the JSON-LD context should look like: ```json { "@context": { "likesOf": { "@id": "https://w3id.org/fep/5711#likesOf", "@type": "@id" }, "sharesOf": { "@id": "https://w3id.org/fep/5711#sharesOf", "@type": "@id" }, "repliesOf": { "@id": "https://w3id.org/fep/5711#repliesOf", "@type": "@id" }, "inboxOf": { "@id": "https://w3id.org/fep/5711#inboxOf", "@type": "@id" }, "outboxOf": { "@id": "https://w3id.org/fep/5711#outboxOf", "@type": "@id" }, "followersOf": { "@id": "https://w3id.org/fep/5711#followersOf", "@type": "@id" }, "followingOf": { "@id": "https://w3id.org/fep/5711#followingOf", "@type": "@id" }, "likedOf": { "@id": "https://w3id.org/fep/5711#likedOf", "@type": "@id" } } } ``` All properties use `"@type": "@id"` since they are functional properties that reference objects or actors. Would it be possible to either add this context definition to the FEP document or set up the w3id.org redirect to serve the actual context? This would greatly help implementers and improve adoption of FEP-5711.
Member

@hongminhee This sounds like an issue with the JSON-LD processor either not doing content negotiation or not following redirects. Can you share which JSON-LD processor you are using that is unable to fetch the context document properly? I can then maybe add guidance to FEP-888d (#83) if needed.

@hongminhee This sounds like an issue with the JSON-LD processor either not doing content negotiation or not following redirects. Can you share which JSON-LD processor you are using that is unable to fetch the context document properly? I can then maybe add guidance to FEP-888d (#83) if needed.
Contributor

@trwnh Oh, it wasn't working when I posted the comment above, but it's working fine now. Never mind!

@trwnh Oh, it wasn't working when I posted the comment above, but it's working fine now. Never mind!
Sign in to join this conversation.
No description provided.