Orie Steele

A much smarter way to join the graphs after import: ```cql MATCH (n1: Resource), (n2: Resource) WHERE split(n1.uri, '-')[1] = split(n2.uri, '-')[1] AND NOT EXISTS(n1.jws) AND EXISTS(n2.jws) MERGE (n1)-[link: DATA_INTEGRITY_PROOF]->(n2)...

Importing objects that might contain blank nodes 1 at a time seems to work: Left hand side: ``` uri: bnode://genid-d10239de14ab4697baa44fdef3190c14-b3 uri: bnode://genid-4eb97b93909d41a19febb7483c8e49eb-b3 uri: bnode://genid-a5218ac4e96f433c8d31bb6a1115c49a-b3 ``` Right hand side: ``` uri:...

Unfortunately, this won't help you with Verifiable Presentations... Because the proofs on the credentials will have a similar blank node identifier as the proof on the presentation: Left: ``` uri:...

I added a similar import for VC-JWTs here https://github.com/transmute-industries/verifiable-data/pull/198 This raises interesting questions, since VC-JWT has an `external` proof... there is nothing to import regarding the proof semantics (without me...

This issue is addressed by: https://github.com/w3c/vc-data-model/pull/927

Should be closed pending PR above.

I'm in favor of considering the a broader family of data definition langauges, including SHACL, CDDL and JSON Schema

There are 2 things being discussed on this issue: #### What is the shape of `issuer` in a `VerifiableCredential`. Today, these are all valid: ```json "issuer": { "id": "did:key:z6MktHQo3fRRohk44dsbE76CuiTpBmyMWq2VVjvV6aBSeE3U", "type":...

I propose we define a schema for VPs in JSON Schema, and that v2 perfectly reflect that schema in normative language.

IMO the schema should be in the same repo with the normative statements that it is built from.