Standards Fields

[matthewhjcrawford]

I think the following four fields should be considered when labelling a Standard

StandardName StandardVersion StandardURL StandardUseCase

Hopefully the first three are self explanatory, but the last one might need explaining. When a Standard is involved we should consider whether it is Implemented (i.e. company A uses it in their deliverable and ships to company B), or Supported (i.e. company A does not use it, but provides support for company B to maybe use it). The different use cases may have difference risks for company A and may carve the second option out of their indemnity where the first might not be. This distinction might be helpful when discussing Standards

[goneall]

@matthewhjcrawford I could use a bit more context - can you include a reference to the property / class / vocabulary that should be updated?

A pull request would also provide the context.

[goneall]

@goneall to ask Matthew and @kestewart to see if we can resolve

[goneall]

@matthewhjcrawford @kestewart - could you take a look at the request and see if a pull request could be created?

[goneall]

@kestewart to work on a draft for version 3.0 RC2

[kestewart]

Talked to Matthew in Cambridge, and there's been some evolution on this. I've got an email from him, and I'll put in the PR if he doesn't beat me to it. They will all be optional properties - but will give us a better foundation than just a single string, and it's something that Armin wanted to see changed anyway.

[kestewart]

Here's a recent example of what StandardName: IEEE Std 754-2008 for Floating point arthrimatic StandardVersion: 2008 StandardSupplier: IEEE StandardHomePage: IEEE.org

From discussion with Gary, this needs to be a class rather than individual properties.

[matthewhjcrawford]

Hopefully this is all self explanatory, let me know if you need any commentary on the fields.

[kestewart]

@matthewhjcrawford - yes they are. Gary and I discussed this in person last night, and were thinking that some of the agent info is probably appropriate for some of the properties. To that end, he's convinced me we should set up a class call "Standard" and then have StandardName and StandardVersion added now. The other properties we can sort out adding in 3.1 if we can't use agents. That work for you?

[goneall]

@kestewart @matthewhjcrawford - @sbarnum and I put some time into trying to model this and we came up with a number of questions and alternatives (e.g. should this really be a subclass of Element so we can share the references to the standard across other elements - also note Element has name and version already). It really depends on the use cases how to properly model.

Since we have these questions, I suggest we don't try to push this into RC2, but take a bit more time and properly model this out.

One suggestion - in the documentation for the current standard property, make it clear that this is a standard name, possibly even changing the name to standardName - this would allow us to create a new property standard in the future and it wouldn't be a breaking change.

[sbarnum]

Consensus of the Feb 06, 2024 Tech call was to pursue changing the currently existing standard property on Artifact to be standardName and to remain a string for now.

A separate issue will be opened to explore, discuss and solve the questions around a more fleshed out and structured characterization of standards post RC2.

[sbarnum]

A PR #631 has been created to implement the above reached consensus.

[goneall]

Based on discussion in the AI meeting on 14 Feb 2024, we'll push this until 3.1 and just rename standard to standardName for 3.0.

[bact]

@bennetkl @rgopikrishnan91 This is relevant to AI and Dataset Profiles. Currently, all we have is standardCompliance - which is basically a free-form text.

[gopirajbahadur]

Except the use case field, I think the other fields are good. For the last one, I think its rather a bit unclear and we might need to work through it. But in principle, I see the usefulness of these fields for 3.1