It is my fault as I should’ve been a bit clearer. First, those names I used were just random examples to indicate dividing into separate vocabularies (might also have used ‘fooDomain’ and ‘barDomain’), and second they are thus part of the namespaces ‘prefix part’ (don’t have the proper terminology, thought we’d just say ‘namespace’ for it).
Example:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"sc": "http://schema.org#",
"video": "https://w3id.org/activitystreams/extension/video#",
"framesPerSecond": {
"@id": "video:framesPerSecond",
"@type": "sc:Number"
},
}
],
"id": "https://conf.tube/w/daJwZp7HhQFK5v3B9L89oY",
"type": "Video",
"framesPerSecond": 60
}
In the example above framesPerSecond is defined in the AS namespace for video-related (i.e. domain-specific) vocabulary extensions. Anyone developing for that same domain (e.g. Peertube, Owncast, Pixelfed when they add video capabilities) can propose new types and properties in this vocabulary.
Whereas, when looking at the current app-specific @context that PeerTube uses:
Peertube JSON-LD context (click to expand)
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
{
"RsaSignature2017": "https://w3id.org/security#RsaSignature2017"
},
{
"pt": "https://joinpeertube.org/ns#",
"sc": "http://schema.org#",
"Hashtag": "as:Hashtag",
"uuid": "sc:identifier",
"category": "sc:category",
"licence": "sc:license",
"subtitleLanguage": "sc:subtitleLanguage",
"sensitive": "as:sensitive",
"language": "sc:inLanguage",
"isLiveBroadcast": "sc:isLiveBroadcast",
"liveSaveReplay": {
"@type": "sc:Boolean",
"@id": "pt:liveSaveReplay"
},
"permanentLive": {
"@type": "sc:Boolean",
"@id": "pt:permanentLive"
},
"Infohash": "pt:Infohash",
"Playlist": "pt:Playlist",
"PlaylistElement": "pt:PlaylistElement",
"originallyPublishedAt": "sc:datePublished",
"views": {
"@type": "sc:Number",
"@id": "pt:views"
},
"state": {
"@type": "sc:Number",
"@id": "pt:state"
},
"size": {
"@type": "sc:Number",
"@id": "pt:size"
},
"fps": {
"@type": "sc:Number",
"@id": "pt:fps"
},
"startTimestamp": {
"@type": "sc:Number",
"@id": "pt:startTimestamp"
},
"stopTimestamp": {
"@type": "sc:Number",
"@id": "pt:stopTimestamp"
},
"position": {
"@type": "sc:Number",
"@id": "pt:position"
},
"commentsEnabled": {
"@type": "sc:Boolean",
"@id": "pt:commentsEnabled"
},
"downloadEnabled": {
"@type": "sc:Boolean",
"@id": "pt:downloadEnabled"
},
"waitTranscoding": {
"@type": "sc:Boolean",
"@id": "pt:waitTranscoding"
},
"support": {
"@type": "sc:Text",
"@id": "pt:support"
},
"likes": {
"@id": "as:likes",
"@type": "@id"
},
"dislikes": {
"@id": "as:dislikes",
"@type": "@id"
},
"playlists": {
"@id": "pt:playlists",
"@type": "@id"
},
"shares": {
"@id": "as:shares",
"@type": "@id"
},
"comments": {
"@id": "as:comments",
"@type": "@id"
}
}
]
Then we see that ‘frames per second’ is defined in app-specific manner as pt:fps. And also we find the app-specific definition of pt:commentsEnabled. Both of these make no sense to exist in an app-specific vocabulary. In the first case, when e.g. Owncast wants to define ‘frames per second’ they shouldn’t have to refer to a PeerTube namespace to do so interoperably.
And in the second case is ‘comments enabled’, if you want to define it in a universal manner, something that doesn’t belong in the AS ‘video’ vocabulary. There are many more app / business domains where you want to add commenting functionality. This property might be part of the ‘core extension’ namespace, or even get its own ‘comments’ vocabulary.
Another vendor-specific extension right now are the toot properties that Mastodon defines .e.g.
{
"toot": "http://joinmastodon.org/ns#",
"featured": {
"@id": "toot:featured",
"@type": "@id"
}
}
Some considerations to make here are:
- Keep as-is given that this is already such widely adopted extension?
- Define corresponding / equivalent vocab at w3id.org and recommend its use?
- Define at w3id.org and also provide a better domain separation?
On point 3) if you look at featured you can see that featuring something is not restricted to toots, so it might be defined in a more generic way, idk maybe in a ‘public relations’ vocabulary.
Other than that, as you rightfully say, best-practice is to use well-defined (general-purpose) vocabularies / ontologies if they exist, so starting with having a peek into schema.org if something already exists makes a lot of sense (see also PeerTube @context above).
I mention ‘general-purpose’ vocabularies. If for ‘toot’ vocab we’d choose option 1) then it’d be considered a de-facto general-purpose vocab. Other vocabularies that are meant to be general-purpose may not be stable enough to be used as such. Example is ForgeFed, where the project has stalled and its status is unclear. The forgefed site may suddenly disappear. For Podcasting a healthy initiative looks to be well underway with podcastindex.org and then using that is a logical choice.
(Btw, note that in the case of ForgeFed there are other thoughts as to how to move forward. “Code forges” are a particular type of application, but they do not represent the business domains well, and these domains are the reason why one chooses a code forge tool. Wrt business domains you can think of ‘Revision control’, ‘Issue tracking’, ‘Project management’, etc. On Discuss Social Coding I have therefore started an initiative to consider the entirety of software development, and defined the “Free Software Development Lifecycle” or FSDL as the top-level domain)