Re: Towards a global taxonomy for DID methods...

I totally get where you are coming from (I too prefer convention over
configuration), but I still wouldn't put that in the DID ID itself, other
than PERHAPS as a hash ie: DID:123456789#structure

This type of resolver stuff belongs in the methods. My reasoning is based
on how I would actually structure the resolution flow:

1. There is a DID with an ID
2. This DID record is owned by any and all entities that possess the
private keys relevant to the published public keys
3. There are methods attached to this DID that do things, have things,
enable things etc.

Until 1 & 2 are validated, nobody cares (and I would argue the DID is
entirely meaningless) if the DID refers to the geolocation of the building
hosting the toaster (of type appliance) or the IPv6 range of all toasters
from a specific assembly line between March and July of 2026.

I feel like EVERY resolver anywhere should theoretically be able to process
the DID. And if my resolver doesn't know what an appliance is because its
schema only knows about virtual currency wallet holdings, then we have both
missed the boat when it comes to interop. This is why I feel so strongly
about using linked-data schemas.

Or am I missing your point?









On Sun, Aug 11, 2019 at 5:26 PM Michael Herman (Parallelspace) <
mwherman@parallelspace.net> wrote:

> Thank for continuing the discussion Daniel.  The point of my original
> question was about, at a high level, what “taxonomy of *DID Methods*”
> would see most appropriate for Countries and Addresses …as Subjects …and
> less so about the schema used to represent a Country, Address, or Location.
>
>
>
> RE: My concern is that (in my opinion) the ID is like an address of a
> house, not a catalog of everything in a house.
>
>
>
> I agree.  For discussion purposes, let’s assume the DID for the house is
> *did:structure:1234*.
>
>
>
> Then that house digital identifier (*did:structure:1234) * might also be
> used to tag a refrigerator, an oven, and toaster. Each appliance, in turn,
> is an individual Subject with its own DID …perhaps in the *did:appliance*
> DID Method space (assuming each appliance has an immutable serial number):
> e.g. *did:appliance:123-456-7890*.
>
>
>
> Your thoughts?
>
> Michael
>
>
>
> *From:* Daniel Thompson-Yvetot <drthompsonsmagickindustries@gmail.com>
> *Sent:* August 11, 2019 9:10 AM
> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>
> *Cc:* Credentials Community Group <public-credentials@w3.org>
> *Subject:* Re: Towards a global taxonomy for DID methods...
>
>
>
> Well, I personally think it would make the most sense to ref something
> from here:
> https://schema.org/docs/full.html
>
> See https://schema.org/Place and scroll to the bottom to see some
> examples, such as:
>
> 1. {
>
> 2.    "@context": "http://schema.org",
>
> 3.    "@type": "Place",
>
> 4.    "geo": {
>
> 5.      "@type": "GeoCoordinates",
>
> 6.      "latitude": "40.75",
>
> 7.      "longitude": "73.98"
>
> 8.    },
>
> 9.    "name": "Empire State Building"
>
> 10.         }
>
> This is what I meant in my last message. I think it makes more sense to
> leverage your mappings in devland, but do them in a standard format that
> uses the same markup as the JSON-LD morphology that the DID spec is already
> leveraging. Specifically, I would put this type of metadata in a service
> object.
>
> My concern is that (in my opinion) the ID is like an address of a house,
> not a catalog of everything in a house.
>
> 11.
>
>
>
> On Sun, Aug 11, 2019 at 3:45 AM Michael Herman (Parallelspace) <
> mwherman@parallelspace.net> wrote:
>
> RE: Extending it is devland business, not spec stuff.
>
>
>
> That’s where I’m headed/why I asked the question.  Also to validate the
> spec in real life.
>
>
>
> After Addresses and Countries, Cows and Calves are next.
>
>
>
> *From:* Daniel Thompson-Yvetot <drthompsonsmagickindustries@gmail.com>
> *Sent:* August 10, 2019 5:26 PM
> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>
> *Cc:* Credentials Community Group <public-credentials@w3.org>
> *Subject:* Re: Towards a global taxonomy for DID methods...
>
>
>
> My thoughts are that we should respect the original intention of JSON-LD
> and provide baseline mapping entry points. The spec should define
> requirements for identifying an entity, and I think it does a good job of
> that. Extending it is devland business, not spec stuff.
>
>
>
> On Sun, 11 Aug 2019, 01:10 Michael Herman (Parallelspace), <
> mwherman@parallelspace.net> wrote:
>
> Take, for example, these 2 classes of (non-fungible) entities where each
> entity in the class becomes a Subject and DID (Digital Identifier) is
> created for each Subject:
>
>    - Countries
>    - [Postal] Addresses
>
>
>
> What are examples of a taxonomy of DID Methods that make sense for
> representing/organizing Countries and Addresses?
>
>
>
> did:country:…
>
>
>
> did:address:…
>
>
>
> What are your thoughts?
>
>
>
> MIchael
>
>
>
>
>
>