contexts: Remove terms not in DID Core Spec #170

rhiaro · 2020-12-14T12:11:46Z

My understanding is the only terms that should be in the DID Core context are terms which are normatively defined in the DID Core Specification.

I've removed publicKey as it was deprecated, and blockchainAccountId because I haven't seen any intention of that going in DID Core (and it's currently defined in the security vocab, as linked in #166).

I left publicKeyJwk and publicKeyBase58 as I believe the intention is to get these defined in DID Core imminently.

…ed in the DID Core specification

OR13 · 2020-12-14T14:10:51Z

@rhiaro we spent a very long time trying to get blockchainAccountId defined in did core context... there are many things in did core context which are not defined in did core... which you have left in here, including verification methods.

I agree with the intention of this PR, but it will have serious usability implications if applied equally.

I think this warrants a call, perhaps only with folks who want to ensure JSON-LD representations are easy to use.

rhiaro · 2020-12-14T14:54:27Z

including verification methods

Do you mean the types? Yes, that was an oversight, I was only thinking about the properties at the time.

The alternative PR to this one would be to add a definition for blockchainAccountId to the DID Core specification.

It's clear we haven't really defined where the line is about what does and does not get to go into the Core context. Agreed we should probably have a JSON-LD people call about this in general.

rhiaro · 2020-12-14T15:00:00Z

To be clear, while I think the cleanest option is for non-Core terms to be pulled in into DID-method specific (or domain-specific and shared, or whatever) contexts, I am also fine with the idea of having a "special" list of terms that are included in the Core context but defined elsewhere (eg. in the security vocab docs), so long as we write down explicitly what these special terms are and explain clearly what the criteria are for you to get your term added to the "special" list or why you can't.

OR13 · 2020-12-14T18:42:54Z

@rhiaro this conversation is one that must be had, thanks for kicking it off.

See also w3c/vc-data-model#759

IMO we will need the following:

terms in the did/v1 context which are defined in security-vocab (blockchainAccoundId)
terms in the did/v1 context which are defined by activity streams (alsoKnownAs)
terms in the did/v1 context which are defined in did core ( ??????????????????? - currently only "service" lol !!!! )

since changing from w3id.org -> w3.org will break any signatures over IRIs.... its worth noting changing where publicKeyJwk to be defined to did core would be a breaking change for JSON-LD, and not doing so would mean admitting that the ccg controls the term definition.... I am personally a bigger fan of the ccg controlling the term defintion, since I can actually fix things in the CCG and I can't fix IANA / W3 specs...

To put a finer point on it... anything with a w3id.org IRI is "not in the did core spec" :)

rhiaro · 2020-12-14T18:50:17Z

terms in the did/v1 context which are defined by activity streams (alsoKnownAs)

strike this - alsoKnownAs is defined in DID Core. When I say "defined in" I mean the human-readable normative definition that says what the term means.

Pulled in from another context - whatever, this is non-normative so we can do whatever makes sense from a purely JSON-LD perspective without the main spec worrying about that.

terms in the did/v1 context which are defined in did core ( ??????????????????? - currently only "service" lol !!!! )

Again, all of the other terms (minus the verification method types) are defined in DID Core, in that there is a description of the term, what it's for, and what abstract constraints ("it must be a string" etc) are on it.

OR13 · 2020-12-14T19:06:59Z

https://github.com/w3c/did-spec-registries/blob/master/contexts/did-v1.jsonld#L21
https://www.w3.org/ns/activitystreams#alsoKnownAs
https://www.w3.org/TR/did-core/#dfn-alsoknownas

@id http://purl.org/dc/terms/created - @type http://www.w3.org/2001/XMLSchema#dateTime
@id http://purl.org/dc/terms/updated - @type http://www.w3.org/2001/XMLSchema#dateTime

Your PR #169

attempts to define https://www.w3.org/ns/did (corrected from v1 to align with the activity streams example)... this yields a 404.

This is super confusing, but I assume it should be like this:

https://www.w3.org/ns/activitystreams#alsoKnownAs -> https://www.w3.org/TR/did-core/#dfn-alsoknownas
https://www.w3.org/ns/did#alsoKnownAs -> https://www.w3.org/TR/did-core/#dfn-alsoknownas

As a developer, I would expect:

https://www.w3.org/ns/did#publicKeyJwk -> https://www.w3.org/TR/did-core/#dfn-publickeyjwk
https://www.w3.org/ns/did#verificationMethod -> https://www.w3.org/TR/did-core/#dfn-verificationMethod

But today, I am seeing:

https://www.w3.org/ns/did#publicKeyJwk (❌ broken link!) -> https://w3id.org/security#publicKeyJwk (✅ working link!)
https://www.w3.org/ns/did#verificationMethod (❌ broken link!) -> https://w3id.org/security#verificationMethod (✅ working link!)

https://www.w3.org/TR/did-spec-registries/#publickeyjwk (✅ working link!)
-> https://w3id.org/security#publicKeyJwk (✅ working link!)

I am not inclined to merge a PR that includes broken links :)

OR13

I think the solution to this is to add a PR to add blockchainAccountId to did core, and I worry that removing publicKey will yield a mountain of broken JSON-LD.

OR13 · 2020-12-14T19:14:33Z

contexts/did-v1.jsonld

    "keyAgreement": {
      "@id": "sec:keyAgreementMethod",
      "@type": "@id",
      "@container": "@set"
    },
-    "publicKey": {


if this term is removed, all examples will need to include the sec context right?

All examples that use publicKey would, yes.

Again, I'm totally fine to keep this in if it's included on the "special" list, and we can define what that "special" list is and how things get added to it.

I think this change would come as a shock to most JSON developers.

Why do JSON developers care?? They don't need @context at all!

I would prefer not to invite incompatibility any more than we already have. My point is that this term is valid in JSON, and you are making it invalid in JSON-LD... without extension... IMO, not a helpful change :)

I think noting that its only defined in security-vocab and warning that its deprecated is as far as we can go, without needlessly breaking a bunch of JSON that was valid for both JSON-LD and JSON before, and wouldn't be after this is merged.

Do you mean the case where a technically JSON-LD implementation just glues the did/v1 context to the top but otherwise treats it as plain JSON, and uses publicKey, and is not at all motivated to correct their now-faulty JSON-LD use because what they really want is plain JSON and to not have to care about this stuff, and are just using the @context as a courtesy but if we try to make them add another line they're going to throw the toys out the pram?

That's fair enough. Valid case I think :)

BUT if JSON-LD implementers are completely prevented from making breaking changes to unstable (and stated as such) v1 context because of plain JSON developers, that's kind of rubbish.

@rhiaro I 100% agree.... and would advise us to never publish an "unstable context" with a URL like "https://example.com/v1" ever again, because people will treat it as immutable.

its why we created https://w3id.org/security/v3-unstable and I push breaking change to it daily :)

rhiaro · 2020-12-14T19:16:19Z

Yeah I think we're having a bit of a miscommunication on what "defined in" means. I'm not talking about pulling terms in from other contexts at all when I say that. As a JSON-LD mechanism for aligning between different vocabs we do that. But my main concern with "defining" is which normative document (not a namespace doc, not a json-ld context, not a CG note, etc.) a term originates in

attempts to define https://www.w3.org/ns/did (corrected from v1 to align with the activity streams example)... this yields a 404.

I thought the WG had agreed on https://www.w3.org/ns/did/v1 as the namespace URI. That's what is in all the examples in the spec right now. So I just used that. Can we talk about that when deciding whether links are broken or not instead of a URI that the WG hasn't (afaik) agreed to use for anything yet? (The did/v1 one resolves only to the jsonld context at the moment. In an ideal world, it'd also point to the registries for html, but that in itself I don't think blocks anything currently.)

OR13 · 2020-12-14T19:48:03Z

@rhiaro I noticed activitystreams handles this differently....

https://www.w3.org/ns/did (broken)
https://www.w3.org/ns/did/v1 (works but is JSON-LD)

https://www.w3.org/ns/activitystreams (works)
https://www.w3.org/ns/activitystreams/v1 (works but is html)
https://www.w3.org/ns/activitystreams/v999999999999999999 (works but is html / error?)

I would suggest did core should behave as follows:

https://www.w3.org/ns/did (html)
https://www.w3.org/ns/did/v1 (JSON-LD)
https://www.w3.org/ns/did/v999999999999999999 (404)

I could also live with:

https://www.w3.org/ns/did (404)
https://www.w3.org/ns/did/v1 (html)
https://www.w3.org/ns/did/v1 (json-ld)
https://www.w3.org/ns/did/v999999999999999999 (404)

^ however I find this generally "less usable" / friendly for developers.

rhiaro · 2020-12-14T19:57:59Z

I would suggest did core should behave as follows:

Happy with either of those. Agreed they're more sensible than what we have now.

This is an adjacent conversation really, but since we're here (and this PR has definitely died a death)..

I'd like to see both html and jsonld documents at /v1 because if the html only lives at /did and we move on to v2 we're potentially going to lose that html snapshot of what was at v1. It does depend on what the html at /did is though. Is it:

a redirect to the Registries?
a redirect to the DID Core Spec?
a new static page that simply lists all of the terms in the context and links out to their definitions (like the AS2 namespace does)?
a new static page that doesn't list the terms at all, but says "hello! you have reached DID land! Here is the Spec, here are the Registries, here are the json-ld contexts!" (etc)

OR13 · 2020-12-14T20:01:28Z

@rhiaro I would prefer

https://www.w3.org/ns/did and https://www.w3.org/ns/did/latest both redirect to latest html / json
https://www.w3.org/ns/did/v1/index.json -> json
https://www.w3.org/ns/did/v1/index.html -> html
https://www.w3.org/ns/did/v1 (content-type) -> html, json

This is also how github pages handles things...

https://identity.foundation/.well-known/did-configuration/v1
https://github.com/decentralized-identity/.well-known/blob/master/did-configuration/v1/index.json

if both index.html and index.json are present, html / markdown takes precedent.

https://stackoverflow.com/questions/39199042/serve-json-data-from-github-pages

rhiaro · 2020-12-14T20:05:30Z

* https://www.w3.org/ns/did/v1/index.html -> html

@rhiaro I would prefer

* https://www.w3.org/ns/did and https://www.w3.org/ns/did/latest both redirect to latest html / json

* https://www.w3.org/ns/did/v1/index.json -> json

* https://www.w3.org/ns/did/v1/index.html -> html

* https://www.w3.org/ns/did/v1 (content-type) -> json / html

yeah that looks good to me. Note we wouldn't need to do the index part because the way the w3c servers are set up /did/v1.json and /did/v1.html would automatically resolve to the right things, in the same way as if you'd done content negotation with accept headers.

OR13 · 2020-12-14T20:08:22Z

So it would be:

https://www.w3.org/ns/did/v1.json -> json
https://www.w3.org/ns/did/v1.html -> html
https://www.w3.org/ns/did/v1 (accept) -> v1.html, v1.json
https://www.w3.org/ns/did/v2.json -> json
https://www.w3.org/ns/did/v2.html -> html
https://www.w3.org/ns/did/v2 (accept) -> v2.html , v2.json

rhiaro · 2020-12-14T20:08:55Z

So it would be:

* https://www.w3.org/ns/did/v1.json -> json

* https://www.w3.org/ns/did/v1.html -> html

* https://www.w3.org/ns/did/v1 (accept) -> v1.html, v1.json

* https://www.w3.org/ns/did/v2.json -> json

* https://www.w3.org/ns/did/v2.html -> html

* https://www.w3.org/ns/did/v2 (accept) -> v2.html , v2.json

Yep!

What remains is: what is the html?

OR13 · 2020-12-14T20:20:57Z

What remains is: what is the html?

I am assuming it can't be:

So it must be some new html we have never seen before... hosted in a repo that does not exist :)

Perhapse we are missing:

https://github.com/w3c/did-core-ns

which hosts html and json and offers urls like:

https://www.w3.org/ns/did/v1 on merges to main.

rhiaro · 2020-12-14T20:25:31Z

I am assuming it can't be:

Well, not necessarily. I don't see why we can't point it at either the spec or the registries. It depends what you want out of it really. If it should just be a fast-as-possible to scan list of terms, then we need something new. But if we don't have time or energy to create that something new (don't worry, I'll do it) then I don't think there's a good reason we can't just point it at the spec or the registries. Perhaps we could do so in the meantime, and see if anyone complains.

I don't think we necessarily need another repo for it though. If it was a super simple static HTML page, and it was up to me, I'd stick it in this repo, in the contexts directory, and update it by hand when needed - which would hopefully be infrequent, and then never again, once the spec is finished and v1 context frozen.

OR13 · 2020-12-14T20:29:23Z

@rhiaro I suggest we do it in this repo, and we ensure it will have github and w3 urls.... I can't help with the w3.org urls, but I can help with the github ones.

I propose we create a folder structure and how that it works in github as a first step, then setup redirects after.

rhiaro · 2020-12-14T20:33:55Z

@rhiaro I suggest we do it in this repo, and we ensure it will have github and w3 urls.... I can't help with the w3.org urls, but I can help with the github ones.

I propose we create a folder structure and how that it works in github as a first step, then setup redirects after.

Sounds good! The hard part is agreeing what goes in the files, the easy part is asking Ivan to put the right files on w3c servers :) (I can get started on this tomorrow - getting late in UTC - if you don't get to it first)

iherman · 2020-12-16T05:46:52Z

The issue was discussed in a meeting on 2020-12-15

no resolutions were taken

View the transcript

2. DID Core vocab

See github issue #404.

Brent Zundel: this was raised by ivan, folks have commented.
… we have 10 minutes or so to talk about it.

Manu Sporny: ivan this is mostly, the question to you - what are the expectations here?.
… we've had discussion, the core thing we're trying to get to is we need a formal RDF vocabulary for DID core.
… what I want to make sure is that we're all aligned on what we need to do to make that happen.
… we've got a human readable part of this which is the registries to a certain degree, it doesn't have rdfa.
… the expectation is that we will probably have some rdf schema definition somewhere.
… I believe that's primarily what you're asking for?.

Orie Steele: Some related conversation on this dead PR.

See github pull request did-spec-registries#170.

Orie Steele: I linked a PR. I had a conversation with amy related to this on the did spec registries.
… it's a PR for a thing that's probably not going to get merged but there's good conversation on there.
… my initial proposal would be lets set up the html side of the vocab definition the same way activitystreams have (see thread) and suse the DID spec registries repo for it for the time being, and work towards getting stable urls behaving in the way we want them to, and then work on setting up proper redirects for the vocab after that.
… from the perspective of what is needed, it's a versioned html and jsonld files and I think we can do all that in the did spec registries and work towards a working solution there before we worry about fixing the top level urls.

Ivan Herman: I was probably not clear in what I wrote, but manu, unfortunately, this is not what I meant.
… forget about RDF.
… I used RDF as an example simply because that's what I understand well.
… the problem is that if you read the document you have a bunch of properties that are defined there and it is not really clear .. two things.
… one is (maybe it has improved) what are the properties and classes that are defined as part of the core standard and what are there as an example.
… I have said that many times.
… and it hasn't been clearly spelled out somewhere.
… and what is even worse is that there are a number of constraints that are not clearly spelled out for the reader.
… the various examples is on the top of my head the id property which in some cases can have only this and this values and in other cases can be used with different values, sometimes only did as a value, some cases you can use whatever url you imagine.
… there are the property controller which can be used on some types of objects and cannot be used somewhere else, what do they mean.
… there is a set of clear definition and constraints that are missing.
… hard to have those constraints spelled out as part of the spec is largely an editorial thing.
… what I did was spell out those constraints for the RDF side by using shacl and I realise that this was more an exercise for myself because you don't necessarily know shacl.
… in a way what I saw done by jonathan for cddl is doing something very similar.
… I am not a real expert in cddl but what I understood is describing more or less the same things.
… I don't care in which format we do that, but the spec must be clear.
… in my reading it is not..
… Apart from that (second issue), yes we define a vocab for the usage of RDF and linked data and yes for that we should have a formal vocab that describes the vocab in terms of rdf.
… that is not the same as the context file.
… it's a RDF specification or something.
… that is something that should be done, it is not necessarily part of the spec, not normative, should be present and reachable, that's something we can do very easily once the spec is out.
… that's okay, that's not the real issue.
… the real issue for me is the proper specification.
… I think that amy began to think about doing some kind of table representation of the terms to express the various constraints.
… that can also work for me.
… it's up to the editors.

Manu Sporny: that is helpful, thanks ivan.
… there are a couple of things that have happened since your review that have improved things.
… we're in the process of really nailing down the ADM and the representations, so hopefully it's far more clear what you can have associated with each property across all representations.
… that's one level of improvement, not done we need another pass.
… hopefully that addresses one of your main concerns.
… the other thing we've got now, jonathan put all that work into the cddl stuff os we have a syntax enforcement mechanism now for things that support it, like json, jsonld and cbor.
… we have that shacl/json schema mechanism but in this case we're using cddl to do that.
… the third thing we have are the jsonld contexts which are in flux but we're getting them shaped up.
… the only missing item is a good rdf vocabulary.
… something that more of the Semantic Web folks could utilise.
… and we should probably look at gregg kellogg's tool that converts csv files into full blow human readable vocabs plus the rdf schema stuff in turtle format and whatever different formats we want.
… I feel like that's the last missing thing.
… that can be autogenerated into the RDF things.
… with all of those things in place my hope is it addresses all the concerns you raised.
… I just don't know if it would.

Ivan Herman: See Draft RDFS Vocabulary.

Ivan Herman: See Draft SHACL version.

Ivan Herman: as I said I am perfectly fine to use cddl for that. If that's the way we do it, that's fine..
… the only question I have and maybe it's an obvious answer, is the cddl part of the normative spec?.

Manu Sporny: no.

Ivan Herman: it should be.
… that's the major point.
… it's the definition of all the constraints in a clearly defined way.
… this is one point.
… the rdf vocabulary I did something back then which is already on our wiki page. this has to be updated because we don't have the whole thing.
… it was not perfect at that point.
… but that is there and as I said if the cddl is normative then this rdfs vocab doesn't have to be normative.
… it is perfectly fine to have it .. it should be properly doen but it's not something that holds up the CR.
… and we can start if from there.

Jonathan Holt: the cddl spec itself is normative and it extends the abnf rules, it is a normative description of the constraints and type definitions.
… which is what I think the rdf attempts to do with symbol representation for concepts.
… as ascii strings, it representation something.

Manu Sporny: Editor's note: It is not normative right now... it would take a lot of work to get it to be normative..

Jonathan Holt: I think cddl tries to not boil the ocean in that way, it really is a constraint satisfaction which is mathematically proven.
… you can do the closures to make sure it captures everything you hope.
… I've demoed that before.
… you can generate examples using cddl which I've found really helpful.
… cddl does have a lot of power to help along the spec and really help constrain it into what types are allowed.
… as we've been finding there are some challenges when you go into an abstracted version of that.
… still a challenge with numbers.
… the number representation in ipld is still challenging to represent when you have limitations with certain representations.

Michael Jones: I push back on the idea that rdf is necessary or even useful.
… if we do that it would be one more parallel representation of what we already have normatively in the spec.
… if we believe the spec is not sufficiently clear in places that ivan described we should make the spec clear.
… we shouldn't fall back to trying to maintain and create a separate parallel representation of the spec.
… I think we should do no rdf work.

Brent Zundel: if we could have those comments occur in the issues I think that would be best.
… issue 404.

contexts: Remove terms that are not and are unlikely ever to be defin…

8a995d3

…ed in the DID Core specification

rhiaro requested a review from OR13 December 14, 2020 12:11

rhiaro requested a review from msporny as a code owner December 14, 2020 12:11

OR13 requested changes Dec 14, 2020

View reviewed changes

OR13 reviewed Dec 14, 2020

View reviewed changes

rhiaro mentioned this pull request Dec 14, 2020

contexts: Explain which terms aren't in DID Core Spec #172

Merged

rhiaro mentioned this pull request Dec 14, 2020

Human readable docs in the DID ns #173

Closed

iherman mentioned this pull request Dec 16, 2020

Precise specification of the DID Core Vocabulary w3c/did-core#404

Closed

rhiaro closed this Jan 10, 2021

msporny deleted the fix/remove-noncore-terms branch November 14, 2021 21:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

contexts: Remove terms not in DID Core Spec #170

contexts: Remove terms not in DID Core Spec #170

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020 •

edited

rhiaro commented Dec 14, 2020 •

edited

OR13 commented Dec 14, 2020

OR13 left a comment

OR13 Dec 14, 2020

rhiaro Dec 14, 2020

OR13 Dec 14, 2020

rhiaro Dec 14, 2020

OR13 Dec 14, 2020

OR13 Dec 14, 2020

rhiaro Dec 14, 2020

OR13 Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020 •

edited

rhiaro commented Dec 14, 2020 •

edited

OR13 commented Dec 14, 2020 •

edited

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

iherman commented Dec 16, 2020

2. DID Core vocab

contexts: Remove terms not in DID Core Spec #170

contexts: Remove terms not in DID Core Spec #170

Conversation

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020 • edited

rhiaro commented Dec 14, 2020 • edited

OR13 commented Dec 14, 2020

OR13 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020 • edited

rhiaro commented Dec 14, 2020 • edited

OR13 commented Dec 14, 2020 • edited

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

OR13 commented Dec 14, 2020

rhiaro commented Dec 14, 2020

iherman commented Dec 16, 2020

2. DID Core vocab

OR13 commented Dec 14, 2020 •

edited

rhiaro commented Dec 14, 2020 •

edited

OR13 commented Dec 14, 2020 •

edited

rhiaro commented Dec 14, 2020 •

edited

OR13 commented Dec 14, 2020 •

edited