OASIS Charter Submission Discuss

I put my comments in the google doc but to maintain provenance (😊) of what I said, I'll repeat to list:

• 1b, 1d: Ideally this document would define provenance, pedigree, and lineage wrt how it will used. Ideally it would reference existing definition but maybe won't be able to. If defs not in this doc, this doc should state TC makes it an early priority to define how these terms will be used in the TC's work and be careful on scope. Note the classic english definition might mean just the origin or might mean the history since origin. Also note the classic definition might just mean geography or might mean more fine grained (eg org or person). The degree the TC will get into these type of issues should be clearly defined in scope. Personally I think all are fair game so important to say that so scope is not overly constrained (ie counter the 'out of scope' arguments before they arise).
• 1b, 1d: is data quality within scope or is just provenance within scope and provenance may be used as input to data quality by the user? The use cases referenced are unclear where the boundary of this TC's scope ends wrt quality.
• 1b, 1d:Trust is mentioned frequently in the document but not in the scope. I recommend you include trust in the scope to the extent you want it considered. Eg if intent is to just adopt an existing definition, you should still include it in scope saying intent is to use/adopt whatever particular def you'd already picked (or say it's open). I don't recommend do you too deep down trust rabbitholes (ie keep it focused on data provenance in trust context) but I don't think you want trust entirely out of scope which is how current scope currently reads.
• 1d wrt "database, table, column": I recommend a broader inclusion in the scope. For example graph databases, NOSQL db's, and data not in a db but just passed over an API. As written, someone could argue those are outside the scope of the TC which I don't think was the intent.
• 1d: the referenced use cases includes "geolocation". It uses the word 'geography' but then describes the use using political boundaries. No mention of persons is mentioned  and no mention of automated tools are mentioned. I would think all of the above (lat/long, country, org, person, tools) are within scope (or at least would be useful to me in determining 'trust' based on 'provenance') and it might be worth specifically saying so.
• 1d wrt domain-specific being out of scope: are you sure you want to make them literally out of scope? I understand you don't want to make the domain-specific, and don't want the corner-cases dorking the majority use cases. But by making them out of scope, you open yourself arguments on what 'highly domain specific' means (I could argue http is "highly domain specific"). Trying to word the positive intent without making parts "out of scope" would be better.
• 1d wrt "bearing": I don't think you are using term correctly. SDO standards development organizations is I believe the term you want.
• 1d wrt out of scope SDO's: You might consider restricting your 'out of scope' to recognized SDO's with ref to whichever official list you want (eg NIST https://csrc.nist.gov/glossary/term/SDO or UN/ITU or whatever). Otherwise you open yourself to something being out of scope because someone opened a github opengovernance group on the topic which would then make it out of scope for you.
• 1d wrt "scope will prioritize": Scopes don't prioritize. The TC can prioritize. Scopes are binary. It is in scope or it is out of scope. I recommend against making "non-AI" out of scope. Simplest change just change "The scope will prioritize" to "The TC will prioritize"
• 1d wrt tagging for AI: will tagging include "mis/dis/mal" information? or will that be beyond 'provenance' to be derived by user (ie the AI/ML system) externally to these specs? I believe it's important to be specific on whether mal/mis/dis-information is within or outside scope of tags entering AI/ML system.
• 1e: I'd recommend an additional bullet with something generic for work beyond your first deliverables. Otherwise you'll have to redo the charter once you reach that point. You probably want 'Other to-be-determined artifacts agreed upon by the TC' with a 'such as ...' is you think of something but leave it open by using 'such as'.
• 2a: include: 
• OSIM Open Supplychain Information Modeling https://www.oasis-open.org/tc-osim/
• DAD-CDM https://github.com/DAD-CDM
• COSAI https://www.coalitionforsecureai.org/
• As a sidenote, I don't see conflict with any these. All 3 probably wished you'd already finished so they could reference and use your output. But they are related so should be listed.

Hopefully this email makes it a little easier to whoever is stuck with making the change log.