-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defined entity names should not be re-defined in UNTP or its extensions #323
Comments
Summary of entity redefinitions in the UNTP domainsScanning the domain definitions, it is only Digital Product Passport
Conformity Credential
Digital Facility Record
Digital Identity AnchorNo redefinitions Digital Traceability EventNo redefinitions |
Solution overviewRenaming the base classSince the base But this has two disadvantages:
Renaming the inheriting classAn improvement would be to rename the inheriting class, so the DPP Composition over inheritanceOne further improvement could be not to inherit the core
So a DPP The DigitalLivestockPassport extension can then extend both the core
With this, the At the same time, the inheritance chain is short due to the combination of composition and inheritance, so a A similar model would be applied to Note: we could potentially get even better/simpler composability in the future using Jargon's interfaces to avoid, for example, SummaryOption 2, "Renaming the inheriting class" would be the simplest change to avoid the current issue, especially if we want to release quickly. Option 3 "Composition over inheritance" seems like a neater solution that enables better extensibility, but may be riskier. |
My instinct says go ahead with option 3 - composition over inheritance. Over-use of inheritance is a painful lesson that has been learned the hard way before. The only thing is I might change some of the choice of class names but that doesn't change the preinciple. |
@absoludity I also think option 3 is best and it's what we have adopted for the BC Mines Act Permit. The extensions should only define terms related to itself. At the end of the day, implementers are free to create extensions as they see fit, we can only make recommendations. As long as the end product is conformant, this is an implementation detail. If my extension only defines one additional field (ex: permitNumber), it makes more sense for my context to only list an additional type with this property, and my schema to only check if that property is there (with whatever rule I want to set for it), instead of testing it as a whole. This way extensions are sheltered from core model updates so I wont need to publish a new extension update every time the core model updates. |
Thanks @PatStLouis, @onthebreeze . I've gone ahead with option 3 and released the five untp domains with 0.6.0-beta9 and then used that to create the 0.4.2-beta1 release of the DigitalLivestockPassport (though I think there's a manual release for that with @ashleythedeveloper does) , all of which are valid jsonld (passing There are two small items related to Jargon which I need to pick next week and see if we can improve them:
aatp-dlp-instance-with-bovineanimal-0.4.2-beta1.json (note that the third context item has been updated to point at the jargon artefact, since the actual one for DLP will be published manually and isn't done yet). [1] Actually, looking at the sample data specifically for |
Thanks @colugo . RE |
I'll see if I can get around to having Jargon throw a warning when |
We are running into a couple of issues while testing a UNTP extension - the aatp DigitalLivestockPassport.
The main trigger for these issues is that we've updated the aatp DigitalLivestockPassport extension to inherit from the UNTP DPP credential, so that now a DLP is a DPP which is a VC (where as previously a DLP was a VC only, but not necessarily a DPP, which would mean it could not be validated as a DPP). This update then requires including the DPP context in the DLP which should not be a problem, except that:
Product
andFacility
, which we then re-define in other domains, such as DCC, adding extra fields. Normally on its own this shouldn't be an issue since (as I understand it) the untp-core entities aren't meant to be included directly in another domain's context unless they are used explicitly as a property type, as they are more like building blocks, butRenderTemplate2024
are included in other domains, they are included as untp-core entities, rather than redefined for each domain)As a result, if a domain such as DCC (or DLP) imports
untp-core
, Jargon will want to include all the "blue" classes such asProduct
andFacility
etc. in the context for that importing domain. But if that importing domain, say DCC, also defines its ownProduct
, then Jargon has to start making decisions about whichProduct
is the correct one and currently merges a bit of both, which causes a re-definition. The reality is that I think we are asking for Jargon to do different things in different contexts, so for example we'd want:Product
to have its own"id": "dcc:Product"
since it is a new entity with extra fields, butRenderTemplate2024
should not have its own"id": "dcc:RenderTemplate2024"
but rather use"id": "untp-core:RenderTemplate2024"
since we just want to re-use the core one in all domains (without re-defining it)It is hard for Jargon to have a "correct" way of interpreting a redefinition of an imported entity and we could avoid this whole situation if we just have a rule that within UNTP (and its extensions) we don't redefine previously defined entities, ever (Alastair can make a rule that ensures that is the case for extensions too).
I'll follow-up with a comment that analyses all the current entities causing this and the different options for avoiding the redefinition while retaining the same functionality.
See jargon-sh/issues#42 for details of where this issue was initially discussed on jargon.
The text was updated successfully, but these errors were encountered: