Agreed, likely starting with having a peek at schema.org as most authoritative …
Best-practice: Use the most authoritative ontologies to define new types and properties in FEP specifications.
- But there are 1,000’s of ontologies and for common AS/AP interop they likely not be fully supported, but subsets are.
I am really wondering how to make an intuitive mechanism for FEP extensions, and one that places as low barrier on any dev to follow it.
- A FEP is a clear specification document, and should follow a consistent template to guide implementers along.
- FEP explains in words, examples, possibly diagrams both the message formats and heuristics (business logic) of an extension.
- FEP must be accompanied by a JSON-LD
@context
document for any additional properties and/or types it defines.
The example of @Sebastian contains additional Video types to define XMP/IPTC metadata, and @grishka mentions app-specific extensions where some of them may be candidates to be standardized in a FEP (but maybe not all of them).
That wouldn’t be intuitive to me if I received such message, as the additional types are non-descriptive. I’d have to go to the FEP website and look up what they are about. If you want to know what FEP’s are applied, then that could be in the app-specific @context
of the message.
(Note: In the following I’m just speculating on the concepts as I lack the experience, so it may not be proper way forward)
If the FEP only specified additional properties it might look like this:
{
"@context": {
"sc": "http://schema.org#",
"xmpSubset": "https://w3id.org/activitystreams/extension/fep-xxx1.jsonld",
"iptcSubset": "https://w3id.org/activitystreams/extension/fep-xxx2.jsonld",
"videoFrameRate": {
"@id": "xmpSubset:videoFrameRate",
"@type": "sc:Number"
},
...
},
"type": "Video",
"id": "...",
"url", "...",
"videoFrameRate": 60,
...
}
If the FEP defined additional types it may look like this (with more intuitive naming):
{
"@context": {
"sc": "http://schema.org#",
"videoMetadata": "https://w3id.org/activitystreams/extension/fep-xxx3.jsonld",
...
},
"type": ["Video", "videoMetadata:XMPBasic", "myApp:FancyMetadata"],
"id": "...",
"url", "...",
"metadata": {
"videoFrameRate": 60,
...
},
...
}
There’s many different ways that this could be designed, and that’s something to get agreement on in the course of FEP standardization process. Things may be sliced differently, e.g.
- A FEP that defines
metadata
container on anyas:Object
- A FEP defining
as:Video
metadata conforming to a minimum profile for added metadata - A range of FEP’s adding very specific metadata for specialized purposes
So in the @context
you can find FEP url’s. If an implementer is using JSON then they can navigate to the URL in their browser to find the spec documentation, and if using JSON-LD they find a machine-readable context as well.
(Note that in the above examples you could also refer directly to the full XMP ontology, and use anything you want from that. That might however imho lead to too much diversity and too little common ground for interoperability among fedi apps. Hence the ‘common subsets’ defined in FEP’s)