DPP schema context? - Githubissues

nissimsan commented 5 months ago

Ref https://github.com/uncefact/spec-untp/issues/6, is there a context which explains what the schema is supposed to mean?

Take issuedBy, that doesn't seem aligned to anything, frankly...?

It's issuer (W3C) of iss (JWT). Let's not suggest alternatives, the world needs less, not more standards!

onthebreeze commented 5 months ago

Yes very good point. But begs more questions.

Should a DPP schema and data be complete irrespective of the carrier envelope? Eg if making an API version or some other credential envelope that doesn't use the W3C VC semantics?
are there two different "issuer' identifiers here? eg the VC "issuer" is a DID like did:web:petesmeats.com.au/1234 whilst the "Issuer" of the passport in a business sense is the party with name "Pete's Meats" and ABN 12345678911?

I note that the sample VC on the page actually uses the VC "issuer" term so doesnt actually align exactly with the model - which is probably a good example. There's always the "manufacturer" property to hold business terms, allowing the "issuer" to remain VC specific and to specifically mean the DID of the issuer.

Contect file is https://jargon.sh/user/unece/DigitalProductPassport/v/working/artefacts/jsonldContexts/ProductPassport.jsonld?class=ProductPassport

nissimsan commented 5 months ago

We should aim to be technology agnostic

onthebreeze commented 5 months ago

agree - we'll focus on just the payload data models (aka the "subject" of VCs) and let the tech community worry about technical interop.

nissimsan commented 3 months ago

There will be a @context file under UN domain.

@onthebreeze , please make a draft context file available.

nissimsan commented 3 months ago

@onthebreeze is this completed?

VladimirAlexiev commented 2 months ago

Hi @onthebreeze and @nissimsan

The context https://uncefact.github.io/spec-untp/assets/files/digitalProductPassport.v0.4.0.JSONLDContext-2e5291773b9d5efdc8fdc28e3d2614ca.jsonld linked under https://uncefact.github.io/spec-untp/docs/specification/DigitalProductPassport is completely dysfunctional.

VladimirAlexiev commented 2 months ago

Alastair Parker and Ashley Harwood asked on slack what is broken. Take this fragment.

{
    "@context": {
        "issuedBy": {
            "@context": {
                "identifiers": {
                    "@context": {
                        "scheme": "xsd:string",
                        "identiferValue": "xsd:string",
                        "identifierURI": "xsd:string",
                        "verificationEvidence": {
                            "@context": {
                                "format": "xsd:string",
                                "assuranceLevel": "xsd:string",
                                "credentialReference": "xsd:string"
                            },
                            "@id": "xsd:string"
                        }
                    },
                    "@id": "xsd:string",
                    "@container": "@list"
                },
                "name": "xsd:string"
            },
            "@id": "xsd:string"
        },

It purports to describe that ProductPassport.issuedBy->Party and then the structure of Party.

But it doesn't say anything similar! Here is a context (presumably to be deployed at https://uncefact.org/untp/context.jsonld) that captures part of the required info:

{
  "@context": {
    "dpp": "https://uncefact.org/untp/DigitalProductPassport/",
    "DigitalProductPassport": {"@id": "dpp:DigitalProductPassport"},
    "issuedBy": {"@id": "dpp:issuedBy", "@type": "@id"},
    "Party": {"@id": "dpp:Party"},
    "identifiers": {"@id": "dpp:identifiers", "@type": "@id"},
    "Identifier": {"@id": "dpp:Identifier", "@type": "@id"},
   ...

Then in payload data you can have:

{
  "@context": "https://uncefact.org/untp/context.jsonld",
  "@graph": {
    "@id": "https://example.com/dpp/1",
    "@type": "DigitalProductPassport",
    "issuedBy": {
      "@id": "https://example.com/party/1",
      "@type": "Party",
      "@identifiers": [
        ...
      ]
    }
  }
}

nissimsan commented 2 months ago

@VladimirAlexiev, agreed 100%: https://github.com/uncefact/spec-untp/pull/54#issuecomment-2042112619

Fix PRs are encouraged!

nissimsan commented 2 months ago

... Fresh Issues are similarly encouraged.

VladimirAlexiev commented 2 months ago

@nissimsan can you reopen this? cc @kshychko @ashleythedeveloper

ashleythedeveloper commented 2 months ago

@VladimirAlexiev, what are your thoughts on the following:

kshychko commented 2 months ago

@VladimirAlexiev, I'm working at the moment on the proper version of JSON-LD context for DPP along with the published JSON-LD vocabulary. I'll post an update here in a day or two.

VladimirAlexiev commented 2 months ago

@ashleythedeveloper @kshychko

ontology and context should not have the same file name (downloading both causes a conflict when saving)
https://untp-ontologies.s3.ap-southeast-2.amazonaws.com/dpp.jsonld# should be something like https://uncefact.org/dpp/. All of the words amazonaws, southeast, jsonld are parasitic
in addition to defining prefixes, at least define @type:@id for object properties
consider also defining terms for the lookup values so eg "transformation" is translated to CURIE dpp:eventTypeCode#transformation

Ontology: https://github.com/uncefact/spec-untp/issues/68

kshychko commented 2 months ago

@VladimirAlexiev, @Fak3 I got the JSON-LD context fixed, but not the ontology yet. It's been published on the test endpoint https://test.uncefact.org/vocabulary/untp/dpp/dpp-context.jsonld - JSON-LD context https://test.uncefact.org/vocabulary/untp/dpp/dpp.jsonld - JSON-LD vocabulary an example json on json-ld playground

Ontology will be fixed next week, and the context file will be updated accordingly.

Fak3 commented 2 months ago

@kshychko in the context you published "identifiers", "productIdentifiers", "batchIdentifiers", "itemIdentifiers", "classifications", "claimedValues" and few others has "@container": "@list". Is it how it is modeled originally? I would guess that we don't need a @list here, because the order of items is not important, and we can leave it as an unordered set, which is the default.

In contrast, traceabilityInformation seems to be correctly modeled as @list, because ordering of events is useful here.

dimensions.weight.unit (and other measured values - length, volume, etc) has "@type": "@vocab". If we want to really make use of @vocab here instead of just @id, we should also specify which vocab it should expand to:

"unit": {
        "@id": "dpp:unit",
        "@type": "@vocab",
        "@context": {
            "@vocab": "https://vocabulary.uncefact.org/UnitMeasureCode#"
        }
      }

This will allow in the actual json-ld data to use short "GRM" as the unit instead of more verbose "unece:UnitMeasureCode#GRM".

There is a repetition of subcontexts for all measured values. We can improve readability avoiding repetition, by moving this subcontext one level up, into "dimensions" property's @context

conformityClaims.topic and traceabilityInformation.eventType has "@type": "@vocab" - the same note as for unit. We should leave it as @id or specify the concrete @vocab to expand shortened terms.

VladimirAlexiev commented 2 months ago

@kshychko, @ashleythedeveloper , @nissimsan

[ ] #80
[ ] #81
[ ] #82 << look at this diagram!

re @Fak3

identifiers... not a list

Agree! Also, this prop name should be changed to singular: same for classifications, dimensions, productIdentifiers etc

traceabilityInformation seems to be correctly modeled as @list, because ordering of events is useful here.

IMHO if you want them ordered, you should order them by time. AFAIR, EPCIS doesn't have any structure to reflect ordering of events.

kshychko commented 1 month ago

@Fak3 , @VladimirAlexiev I updated the DPP ontology, context and schema files on the test endpoint with some fixes:

identifiers -> identifier etc.
@list -> @setfor all properties except traceabilityInformation
additional context for properties with @vocab type
move value and unitto dimension context (@Fak3 , could you please check if I did it right, it doesn't work for me, but I could miss something)
Fix conversion to ttl with riot (#80) - had to remove proof object from the example, but it uses the deprecated type anyway so needs to be fixed.

@VladimirAlexiev I haven't addressed the points listed on #82 yet, but I'll get there.

The links are the same: the test endpoint https://test.uncefact.org/vocabulary/untp/dpp/dpp-context.jsonld - JSON-LD context https://test.uncefact.org/vocabulary/untp/dpp/dpp.jsonld - JSON-LD vocabulary an example

Fak3 commented 1 month ago

@kshychko

move value and unitto dimension context (@Fak3 , could you please check if I did it right, it doesn't work for me, but I could miss something)

In your json-ld playground example The outer Verifiable Credential has type ProductPassport and at the same time the credentialSubject of this VC also has type ProductPassport - this is wrong. We should decide if the VC itself is ProductPassport or is it credentialSubject? cc @onthebreeze

This issue is most likely caused by json-ld playground bug - it is very confused by both nested objects having the same type and silently drops some terms. But nonetheless, we have to decide what is ProductPassport and only apply the type once.

uncefact / spec-untp

DPP schema context? #8