# Supply Chain Traceability Vocab
Tuesdays 1.30-2.30 EST
## Future Topics
- Next Steps for Traceability Vocab
## Apr 13
- how to regularize the work item procedure and get this open to the CCG
- Manu: Emails to CCG list need [AGENDA] prefix and date/time in subject, agenda in body. followup email with notes also good.
- Juan: Since I didn't send the Agenda link, but there are people from CCG here. Shoudl we have the meeting? Happy to end early, send out proper email, for next week. We could spend time trying to make the next call productive.
- Orie: We should cover procedure and run next week's as a public call; as long as no substantive proposals THIS call, I'm happy to provide feedback and talk about the proposal
- also happy to cover VC-HTTP-API backstory
- Manu: I share the frustruation and want to get the procedure sorted and propose a strategy that adds less work to all of your schedule, but we don't have quorum
- Orie: We have given a lot of work to V-H-A and I agree that we don't have enough UCR there; everyone seems to contribute only to the extent that it helps their use cases
- Markus has his own opinion about it; wasn't it originally created as part of a Danube contract?
- Orie: We're building stuff, we know what the API should do, to some degree it's not exactly lying but kinda transitive interoperability -- A === B, C supports B, therefore A supports C. There's nothing wrong with that, it's just not good enough. The first version of anything isn't right - the first version of the VC HTTP API isn't good -- took a year to get a revision -- pacing is too slow for our needs - interop space. We've moved the Traceability vocab faster, git pull request -- merged even if they're not super great. Others come in behind that fix them. Mesur has fixed problems I created, etc. We have been operating in a healthy and productive way. It's totally different from what it is like to work on VC HTTP API. Not that future of Traceability API overrides VC HTTP API -- only way for it to become broken would be for VC HTTP API changes. I'll stop there -- other companies, other than Transmute - Direct Exchange problem -- postman collection test work - excited to invest on those flows across multiple parties. Test different interop flows, different mechanisms, doesn't do stuff that we want it to do. In a way it's a fork, but in a way it's not -- doesn't make sense to include them, as Markus agreed in a PR.
## Apr 6
- Trace vocab cleanup
- Contexts being injected into properties --> lets edit that out
- PR welcome
- Examples of every object? whole creds only? big creds only? full VCs only?
- JSON Schema should break out what's a VC, what's just an object (evidence doc, for ex.), etc - tagging system?
- Maybe tagging system is clearest way not make everything a VC? Or some kind of JSON Schema magic?
- Mike: There are JSON Schema ways; we could also just an 'object' property for metadata
- Orie: Spec defines which VCs are relevant in our use case preamble, but the data model itself should allow some kind of tagging for "shared", "ecommerce", "steel", "commodities", etc
- Orie: Non-VC objects and shared objects (i.e. bases to be extended by specific VCs)
- Sidebar: GTINs and sGTINs; should we be extending or varying from GS1? Adding examples of prior art makes Trace Vocab look good
- Mike: Metadata tag with a ref? (make it optional with set required false)
- Orie: self-describing JSON Schema (//adtech world)
- $metadata string? $linkeddata? $comment? (test against common JSON Schema parsers to make sure none of them barf)
- Juan will open GH issues about the above & invite CCG to attend next week
- domain-link credentials (link to DIF well-known spec, for ex) & GTINs aren't in the spec now but should be
- examples of both should be a high priority
- Discovery should be specified in the UCR portion of trace vocab?
- Would more sophisticated discovery mechanisms need to be spelled out a new API spec?
- Presentation Exchange has its pro's and con's
- includes suite-compatibility declarations
- Credential Manifest might also help discovery for issuers (early stages)