It’s a list of link objects and not URIs because we may want to add additional properties to them.
That doesn’t require Link objects, but I’m not. suggesting removing the Link objects but only suggesting not requiring them,
silverpill:It’s an ordered list because JSON arrays are ordered (although I think the order shouldn’t matter).
JSON-LD supports both ordered (@list) and unordered collections (@set). If ordering doesn’t matter, implements should be declared as a @set(which is the default for an @id type if there’s no collection type specified in the context).
Is there a practical reason for using
id? This would be a breaking change, and I don’t want to do that just for the sake of theoretical purity.
The implementsproperty is already declared in the context to be a collection of @id. The question is why the FEP requires those IRIs to refer to Link objects even if no property beyond href is provided in the actor serialization (versus in a external LD document).
It’s not a breaking change to not require all capabilities to be Link objects. They would still be allowed. It just seems like an unnecessary requirement rather than a “theoretical purity” issue (not sure what that means in this case).
think user’s preferences should be clearly separated from application capabilities. This FEP is focused on the latter.
For C2S client purposes, knowing a server implementation has capabilities A, B and C is not particularly useful if an actor has disabled A and B or if some of those capabilities are disabled by server configuration.
Thanks for the information.