"Lax" IRIs

[pfrazee]

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:

1. Whether a "Lax" IRI would be a net benefit.
2. 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.

[workergnome]

A third issue to consider is that it's very difficult to prevent malicious redefining of a "Lax" IRI. Assuming I am better at SEO than you are, I can redefine the meaning of your IRI by providing an alternate definition of your term on my website, and there's nothing you can do to prevent that, nor is there any way to determine which definition is the 'correct' one.

On many, many cases, people mint URIs, but don't bother to make them dereferencable or provide documentation at that location. But they typically do it on a domain that they own, which provides at least some level of verifiability that the URI is tied to something.

If you're opposed to using DNS, You could likely solve the same thing with a cryptographic hash, a blockchain, or some other math-based means--but that seems even more complex, and doesn't provide the benefits that dereferencability provides when you do want to provide documentation around what that URI means.

[BigBlueHat]

@pfrazee interesting thoughts. Much of them seem to be based around this list:

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).

None of those are actual IRI requirements. 😃 IRI's have a particular shape in order to be distinct from plain text strings. Particular IRIs come with other advantages such as direct de-reference-ablility (i.e. http://) or globally documented authority (i.e. urn:isbn) or public-key based address-ability (i.e. dat://) or content address-ability (i.e. ni://). However, as identifiers none of those advantages directly effect their ability to identify.

So...here's a valid variation on the string you posted above:
https://github.com/pfrazee#pfrazee-social-media-feed-item

or if you'd rather people nag you about what that string means via Twitter, you could do this:
https://twitter.com/pfrazee#pfrazee-social-media-feed-item

Regardless, you've made an identifier that fits the description you posted, isn't quantifiably harder for a developer to construct, and at least comes with some of the additive advantages one gets from something starting with https:// (but certainly you could use dat:// etc).

Lastly, the IRIs don't have to return something meaningful (as identifiers at least), but obviously there are advantages when you use hypermedia to do hypermedia type things--like return meaningful responses for humans and/or computers. But as identifiers they are as easy to craft as any other name for something.

Hope that clears it up a wee bit. 😃

[pfrazee]

@BigBlueHat Useful observations, especially the "place for people to nag you" idea. Thanks.

[gkellogg]

Deferred to WG due to https://json-ld.org/minutes/2018-04-10/#resolution-3.

[gkellogg]

Closed in favor of w3c/json-ld-syntax#14.