Continuing the discussion from Schema for Blockchain ID User Profiles - v3:
Let’s come up with a set of conventions for blockstore namespaces and the default namespace, .id
I’ll start this off with two questions:
My first reaction re organizations and people is to have them in the same namespace. In a way this is already happening e.g., https://onename.com/usv and people are used to using the same namespace on Twitter as well.
I do like the idea of creating a small number of other namespaces e.g., for Internet of Things. However, I feel that the issue there is the cost of the namespace. We had a strong enough incentive to start and actively use .id that we went ahead with paying the fee to start the namespace. Ideally, we should find someone who has a strong incentive for actively using a namespace and is willing to pay the fee to start that namespace.
In my experience, people expect to be able to create identifiers for the business or brand. If we look at how domain names evolved, the initial attempt to restrict .com to commercial, .org to non-profit, geographical domains almost entirely failed. The TLD you select is for vanity only.
There’s also a need for entities and organizations to identify and authenticate as themselves.
I also think we should start initially with having organizations in the same namespace. Then, we can take it from there. If someone starts a new namespace specifically for organizations and it’s working out well, then we can shift conventions.
Also, I’d point out that we’re going to have different schemas for organizations and people. However, this shouldn’t be a problem as with the new schema.org system, each object is designed to identify the type of object it is.
As an example, this object self-identifies as a person:
{
"@type": "Person",
"name": "Naval Ravikant"
}
…so resolvers will know to interpret the JSON according to the fields outlined here: http://schema.org/Person.
So in general, resolvers will know how to interpret each JSON object and know whether it’s a person or organization.
This is very interesting. I have the same issues at CommonAccord. We need info that will complete documents and need to be able to express complex, ad hoc, relationships among persons. In fact to connect them all up in the myriad ways they are connected. Also to connect them with places, properties and things.
Our model is a graph, and an object inherits properties from all the objects it references. We have done this on a totally improvised basis, but have found that individuals and the vast array of different kinds of “legal persons” share a lot, but are endlessly varying in (important) details.
I hadn’t connected this to Schema, which looks like a very good thing to do. I just made an object for it and will play around.
As an example of what we do: the first item in this list of files (01) shows just two persons, one a corporation and the other natural. Acme should be something like corp - Delaware - entity -> person (missing two steps) and Roberta is female -> individual - person. There could be other steps for finer grind. And of course each will have roles.
So … a way of handling this is to let objects inherit properties. That provides flexibility. Those who like a particular solution can gravitate (and militate), while others are free to innovate (and be left alone).
The first file here just connects two person objects. It gets used in the subsequent ones.
http://www.commonaccord.org/index.php?action=list&file=GH/FutureCommerce/ULOM/Bryan/Demo/