Re: [PROPOSED WORK ITEM] Citizenship Vocabulary

On 9/25/20 9:20 AM, Orie Steele wrote:
> I'm fully supportive of this, but wondering about the mechanics.

All great questions, just my $0.02 below:

> There are a number of other vocabularies that are related to DHS SVIP,
> including vocabularies related to supply chain traceability and proof of
> origin for steel, timber, oil, and agricultural products.

... and if the SVIP program is successful at getting things into
production, the number of vocabularies are only going to increase.

> Today, many in this community make use of:

This is a good thing -- vocabulary re-use.

> Many of the W3C CCG vocabularies use the perma-id redirection service,
> which gives them nice names, for example:

It could be argued that this is a bad thing... not because the
service is bad, but because there seems to be a propensity in W3C WGs to
"own" the namespace and eventually do something like:

... which, for those of you that remember history, is funny because W3C
rejected doing that many years ago, which is why we ended up creating
the redirection service.

Remember, the reason W3C didn't want to be put in the position above was
because of the XML DTD Distributed Denial of Service attack the Internet
waged against W3C servers for years due to terrible software
implementations not caching DTD documents.

I expect that there needs to be a discussion between the W3C CCG, W3C
VCWG, and W3C Staff on the right path forward here. We're not exactly in
a good spot right now.

> I am wondering if there is a more general opportunity for W3C CCG to
> define a best practices guide for handling this, or drive towards more
> consistency.

+1 to drive towards more consistency while keeping in mind that
decentralized vocabulary development is a feature, not a bug.

> It seems we have a couple of options, we can keep making individual
> repositories or we can make a single repository for all vocabularies
> developed for DHS SVIP.

Strong -1 to doing a mono repo around DHS SVIP. This is a global
standards setting organization and creating things for any particular
nation state does not do that nation state any favors. At best it'll
create something that's politically radioactive and harm
interoperability (Oh, the US has their own Citizenship vocabulary...
then OUR country needs it's own Citizenship vocabulary!). This is an
anti-pattern wrt. global standards -- these standards are for the world,
not any particular nation state.

We have extensibility if nation state's desire to do their own thing...
they can use the base, and then extend on it for their nation-state
specific use cases.

> There are a number of advantages for co-locating the vocabularies,
> particularly for discoverability, consistency and driving contributor
> engagement.
> 1. Better SEO for DHS SVIP

I don't think DHS SVIP cares about Google Search Rankings, but I'll
defer to them on that.

If they do care, I'll remind them that doing something preferential for
any particular nation state will almost certainly harm the work across
multiple dimensions (political and interop for starters).

> Individual vocabularies are still possible, but vocabulary re-use is
> easy to encourage:

We should be encouraging vocabulary re-use across everything we do. It's
a best practice. The only time you should invent a new vocabulary term
is if:

1) It doesn't exist anywhere else, and
2) You can't convince another more appropriate vocabulary to
   create the term

> 2. Easier to share vocabulary
> There may be cases where common terms are shared across vocabularies or
> DHS SVIP topic areas, in these cases they can be defined once and
> imported by all vocabularies:

Unfortunately, common terms often require you to 1) predict the future
if the vocabulary development cycles is fast, or 2) establish a
placeholder for common terms early and add to it during a multi-year
development cycle.

> Possibility to share some JSON Schema  / SHACL files for things like
> physical address, postal address, and organizations.

Those are all terms. We should try to convince them to add
JSON Schema/SHACL files for those terms as supplementary things for

> To argue against a single repo for DHS SVIP vocabularies:
> 1. Contributors may see more activity in areas they are not directly
> involved with, this might feel like a request to do more work (even if
> we agreed no review / feedback was required).
> 2. There might be too much contribution (too many issues, comment
> threads, pull requests)... speaking from experience, I think this is
> incredibly unlikely : )
> 3. Easier to get free labour from others. Sometimes helping is hurting /
> encourages learned helplessness.

Good vocabularies are often built by focused communities with experts
that are engaged in the process. If I work on citizenship benefits
cards, I don't want to see stuff about importing steel... it has nothing
to do with my area of expertise and interest.

Ideally, there would be strong consistency across all of these
vocabularies. History shows us something very different. is a
hodgepodge of stuff that has been of interest to the Search Engine
companies and those that want to show up in Search Engine results. It's
messy and cross-functional. I'd like us to avoid doing the same here...
but we should re-use what's there instead of creating our own perfect
vocabulary kingdom here.

> If the
> community decides we prefer to have separate repositories for each dhs
> svip vocabulary, expect a similar proposal for a work item for steel
> traceability soon :)

Let's keep them apart for now. Linked Data does not require you to have
a grand vocabulary plan before you start, it largely focuses on
progressive refinement and addition. Merging data and vocabulary terms
are built in to the technology because we learned long ago that doing so
matches the way developers work and ecosystems develop.

Happy to be challenged on any of this. :)

-- manu

Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches

Received on Friday, 25 September 2020 14:29:59 UTC