added simple root Event and fixed OGBillOfLading Generator #164
Conversation
| "description": "The organization performing the activity.", | ||
| "type": "array", | ||
| "items": { | ||
| "$ref": "https://w3id.org/traceability/schemas/Organization.json" |
There was a problem hiding this comment.
Do we want this to be an org? or is entity possibly better? We at least also deal with individuals in the supply chain where Person sometimes is a better representation than Organization
There was a problem hiding this comment.
I had misgivings on whether we should have two fields or just one for this, I wanted initially to have an actor and an actingOrg field.
An entity might solve the problem. good shout
There was a problem hiding this comment.
I would prefer use of Entity
| "description": "Time when the event took place", | ||
| "type": "string" | ||
| }, | ||
| "products": { |
There was a problem hiding this comment.
I am going to have to mull over use of Product here. I think it is probably correct, but also thinking about raw materials becoming a product etc.
There was a problem hiding this comment.
see note from @OR13 below - should this be GS1 or schema.org? Other aspects of the vocab are utilizing schema.org
There was a problem hiding this comment.
Consider "inputs" (raw materials, outputs from other processes/sources, etc.) and "outputs" (refined version of inputs becoming inputs to other processes/consumers, finished products, etc.). These can then be easily turned into a complex trace from most-basic-origin (e.g., extraction of various ores from deep underground) to most-refined-consumable (e.g., a smartphone, tablet, or computer)...
| "description": "Location where event took place", | ||
| "$ref": "https://w3id.org/traceability/schemas/Place.json" | ||
| }, | ||
| "eventTime": { |
There was a problem hiding this comment.
we may want to actually record a few more things here (possibly optionally), e.g. scheduled or planned start time, planned duration, actual start time, actual end time, etc. open on this.
There was a problem hiding this comment.
I would prefer ability to record at a minimum
- event start time
- event end time
There was a problem hiding this comment.
I think this makes sense to split up, probably another base object that encapsulates eventTime that would have the planned start/duration etc.
|
@mprorock can you clearly state what changes need to be made in order to accept this PR? potentially we can open issues to track them and iterate? |
| } | ||
| }, | ||
| "eventLocation": { | ||
| "$comment": "{\"term\": \"eventLocation\", \"@id\": \"https://w3id.org/traceability#eventLocation\"}", |
There was a problem hiding this comment.
I am not sure we want to be defining "eventLocation"... can we use an existing ontology for this field?
There was a problem hiding this comment.
+1 I think this should be a Place
There was a problem hiding this comment.
absolutely should be place
There was a problem hiding this comment.
https://github.com/w3c-ccg/traceability-vocab/pull/164/files#r634604678
^ this is the only critical objection I have, we need to be cleaning up our examples and avoid context nesting.
|
Removed child context @mprorock i deleted the generator and addressed most things in this conversation except for the event time stuff. would it be ok if i open an issue and assign it to you? |
let's not worry about the event time stuff as a blocker for now - we can add that as a later detail when required - probably as a subclass of this (e.g. event with duration or something like that) |
|
On the call we discussed giving this one for day for reviews. |
There was a problem hiding this comment.
Made many description strings more consistent with each other (start with article, close with period, etc.), particularly in ontology. Some sample data is not good English (sentence fragments, primarily) but I'm not always sure what was intended, so some are now unchanged — but will want followup attention.
packages/traceability-schemas/src/__fixtures__/Event/credential.json
Outdated
Show resolved
Hide resolved
packages/traceability-schemas/src/__fixtures__/Event/credential.json
Outdated
Show resolved
Hide resolved
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
These proposed changed look good to me, @mkhraisha can you approve them / reject them so we can see where any gaps are remaining? |
|
Feels like the generators may be getting in the way of having "realistic fixtures"... we should continue to discuss this on the related open issues. |
|
Generated files should generally not be in git repos. Whatever can be done to shift things so that the generated files go to github.io or similar would be best. |
…l.json Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
…l.json Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Apologies for the delays in tackling this. |
|
This looks good to me. |
Adds a base "Event" Schema that captures very simple information.
This schema should be extended by the following EPCIS event types:
This PR is meant to spark conversation on what fields need to be in the base Event vs one of the Event Types