Consider moving controversial terms into an extension vocab

[melvincarvalho]

The Security vocabulary is used to enable Internet-based applications to encrypt, decrypt, and digitally sign information expressed as Linked Data. It also provides vocabulary terms for the creation and management of a decentralized Public Key Infrastructure via the Web

Love the idea and would like to reuse the cryptographic primitives in this vocab for linked data related projects

However, some terms, in particular, ethereumAddress, would be considered highly controversial in the cryptographic community. One of the reasons for this is that it had a premine (some estimates as high as 70%), making it not as appropriate as some in royalty-free standards

This is a wide ranging sentiment, spanning, I would guess, dozens of thought leaders, 100s of companies, 1000s of cryptographers, millions of users, and 100s of billions of dollars in investment

In contrast, terms such as publicKeyPem, are uncontroversial, have a wide range of use across the web

The nature of web documents is that you cant take one term without pulling in all of them. So in a smart semantic agent (e.g. like tabulator and derivatives) which has auto complete on predicates, as soon as you type some characters, it would pull in the predicate, making an end user perhaps think that ethereum addresses were endorsed. One would have to code round this, to remove those terms, or instead fork the vocab creating a duplicate of effort

The vast majority of terms in this vocab are imho completely uncontroversial. Could we consider moving the more controversial ones to its own extension vocab, as linked data was designed for. Similar approaches have been taken by sioc and schema.org etc.

I suspect focusing on a core set of uncontroversial predicates (to encrypt, decrypt and digitally sign) may be a way to get this and related work through the standards process more quickly and easily. The main purpose in raising this issue is to try and gauge the future direction of this vocab, as we decide whether to reuse to avoid duplication of effort