Initial definition of Extension namespace

[sbarnum]

No description provided.

[sbarnum]

It looks like the checks on this may have failed due to the inclusion of an "Remote Classes" section within the extension.md property specification.
This is a new concept but is required if we want Extension to be in a separate profile/namespace.
Typically all SHACL NodeShapes (with accompanying property shapes) will be defined directly from the Class specification file.
In this case to avoid having to specify the property shape for 'extension' on the Element class in the core namespace which would invalidate the concept of Extension as a separate profile/namespace, there needs to be an additional SHACL NodeShape targeting the Element class and asserting the property shape (no cardinality constraints; only path name, nodekind and class) for the 'element' property but it must be defined in the Extension profile/namespace.
To accomplish this I introduced the nomenclature of "Remote Classes" as a specification section on some properties that asserts SHACL shapes that need defined within the local profile/namespace for that property on the referenced "remote" (outside the local namespace) Class. While the case of 'element' property on Element is zer0-to-many and thus has no cardinality constraints other potential uses of Remote Classes in the future may.

[goneall]

@sbarnum - thanks for writing this up. On the remote classes, we can open a PR for the spec-parser to understand the section.

Currently, the spec-parser generates a model file with OWL and SHACL and a separate JSON-LD context file.

Can you document what should be added to these files? We can then update the spec-parser unless there are objections to the format.

[goneall]

@sbarnum - could you also add a profile.md for Extension which describes the profile?

[zvr]

I'm not sure I understood what "Remote Classes" is about.

Are you saying that this PR introduces the property extension (an object property with range of Extension) and this property is on the Core/Element class?

If yes, the way we have done it until now is to actually modify the Core/Element class.

[sbarnum]

I'm not sure I understood what "Remote Classes" is about.

Are you saying that this PR introduces the property extension (an object property with range of Extension) and this property is on the Core/Element class?

If yes, the way we have done it until now is to actually modify the Core/Element class.

Yes. This PR introduces the property 'extension' (an object property with range of Extension) and this property would apply on the Core/Element class however it is defined within a separate profile with a separate namespace and therefore cannot be expressed as a modification to the Core/Element class specification in core.
If it was defined as a modification to the Core/Element class specification in core then you could not separate conformance to the core profile without conformance to the Extension profile from conformance to the core profile with conformance to the Extension profile.
By specifying Core/Element as a 'Remote Class' on the extension specification within the Extension profile/namespace it can be used to generate a separate SHACL shape in the separate SHACL file for the Extension profile/namespace and only be applied when the content claims conformance to the Extension profile.

[sbarnum]

Currently, the spec-parser generates a model file with OWL and SHACL and a separate JSON-LD context file.

Can you document what should be added to these files? We can then update the spec-parser unless there are objections to the format.

If I understand correctly the current approach for SPDX 3.0 is to create a single monolithic OWL and SHACL file for all of SPDX. The upside of this is reduced complexity in dealing with how separate file-based namespace imports work. The downside is increased complexity in trying to validate against specific profiles that include only certain namespaces.
My understanding that the monolithic ontology/shapes file should at least utilize different namespace prefixes (on class and property definitions) for each of the namespaces in SPDX (the folders under 'model' in the prose spec).
Given this, the OWL/SHACL file should contain the following due to this PR (all prefixed to the Extension namespace):

• owl definition for the Extension ontology (namespace)
• rdfs/owl definition of Extension class
• shacl nodeshape for Extension class
• rdfs/owl definition of 'extension' property
• shacl nodeshape targeted at the core:Element class and asserting the property shape for the 'extension' property on that class

I am unaware of a formal decision yet on what exactly will be in the jsonld context file.
I would propose that it should include:

• a 'extension' prefix entry for the Extension namespace
• an entry for extension:Extension associating the specification IRI of the extension:Extension class definition and its type
• an entry for extension:extension associating the specification IRI of the extension:extension property and asserting it as @id type (because it is an object property and this lets you just use the ID string in serialized content)

[sbarnum]

@sbarnum - could you also add a profile.md for Extension which describes the profile?

I am unclear where this would go and what i should use as an exemplar of what you are looking for.
Could you outline a little more what you are looking for?

[goneall]

@zvr and @sbarnum to sync up and resolve

[zvr]

Minor fixes to the way we reference other namespaces, and then it can be merged.

[goneall]

It looks like the spec-parser is failing with this PR. I'll see if I can narrow down the issue.

[goneall]

It looks like this is caused by having a profile by the same name as a property.

I created spdx/spec-parser#82 in the spec parser.

@zvr - any ideas how to fix?

We could work around this by either renaming the property or renaming the profile.

[zvr]

@goneall the new parser, completely rewritten from scratch, does not have such issues.

[goneall]

the new parser, completely rewritten from scratch, does not have such issues.

Where is the new parser implemented?

[zvr]

Where is the new parser implemented?

https://github.com/spdx/spec-parser/tree/new-parser

[goneall]

@zvr - how soon before the new spec-parser is ready? I noticed it isn't processing args yet - so I wasn't able to test with this branch of the model.

[kestewart]

per Jeff on the call, the new spec parser issues should now be resolved.

[goneall]

LGTM