You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of my chief concerns for using JSON-LD in the Beaker/Dat ecosystem is that vocabulary IRIs will be too burdensome for developers to create and maintain consistently. I think often it will be done, but many times devs won't be bothered.
To counter that, I'd like to investigate a "Lax" IRI form which allows an arbitrary string to be used. The string would not be registered to any global ownership system (not DNS, not a urn registry, not a public key, not a content hash). Users would be encouraged to use a string that is long and unlikely to collide with other strings, but there would be no enforcement mechanism. For instance, 'pfrazee-social-media-feed-item'.
The goal would be to create identifiers which behave like IRIs, but which are human readable and which don't require any registration and maintenance of the ID. Rather than a locator to documentation, the Lax IRI would be a label which could be used to discover documentation (on Google, etc). The original author of the identifier would ideally publish documentation somewhere searchable, but it would not be required. To continue from my example, I'd publish a document labeled pfrazee-social-media-feed-item.
I've not found any existing IRI scheme that matches my description yet.
There are probably two discussions to have in response to this exploration:
Whether a "Lax" IRI would be a net benefit.
Whether there's an alternative that achieves the same goals.
As for whether it would be a net benefit, the reasoning I'd give is that some information is better than no information, and if developers are going to abstain from providing a vocabulary IRI because of the difficulty, wouldn't it be better to have a low-effort solution? A "lax" IRI trades total specificity for improved specificity. And, bear in mind, many developers in my audience are going to be building for fun.
A valid counter-argument to my reasoning is, if you create the "lax" option, you may get more IRIs overall, but you risk getting fewer "non-lax" IRIs overall. (Once the option to be lazy is given, then won't everybody be lazy?) So the precision of the global system might suffer overall.