Reviving this thread regarding unification of the SPDX data model across formats and implementations:
I recently discovered you can generate UML diagrams from python code using pyreverse[1] which comes bundled with pylint. I wonder if we could try out creating a python data model as the one model from which diagrams and documentation (and possibly implementations in other languages) may stem from. [1] https://www.logilab.org/blogentry/6883 Nisha From: <[email protected]> on behalf of "Alexios Zavras via lists.spdx.org" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, April 22, 2020 at 2:14 AM To: "[email protected]" <[email protected]> Subject: [spdx-tech] SPDX data model Hi all, As some of you may know, we have been using an ontology (expressed in OWL) to represent the SPDX classes and attributes; we also have a graphical representation of the SPDX data model. These reside, respectively, in the directories “ontology” and “model” of the spdx-spec repository. Although these essentially represent the same thing, for historical reasons they were actually independent “sources of truth”. We all know the disadvantages of such an approach (duplicate effort in maintaining, diverging data, …). I worked, therefore, on producing a graphical representation from the OWL ontology. I actually generate PlantUML, which then generates the diagram using GraphViz. Gary was kind enough to review the initial results and thought we might consider it for the future. I attach a couple of generated files. Quick notes: * The attached data is a DRAFT of an interim state. Do not use for any serious purpose. Consider it only Proof of Concept. * The generation is still a hack and not a very polished solution. So, the distinction between “class” and “enumeration” (noted by “C” or “E” in a circle in the diagram) is not very robust. Unfortunately, in OWL everything is classes… * The only arrows (relationships) depicted are: * Solid lines with white triangle: the typical way to represent “subclass of” * Dotted lines with arrows: a class points to the class of an element * There is no information like “1:N” on purpose; it’s a little confusing to have a class diagram also look like an entity-relationship one. * You can see the (deprecated) “Review” class in the upper right of the diagram, not connected to anything. This will be fixed in the ontology. * You may also notice a brand new “LicenseExpressionDRAFT” class, abstracting away all details about licenses, operators, license list or LicenseRef entries, etc. I felt this level of detail inside license expressions confused the “SPDX-info” side of things. We probably can have a separate diagram about license expressions, without confusing the “core” classes and data model. May I please ask you to review the graphic, tell me whether it’s useful and point out other information you would like to see included. If there are no major disadvantages, we will consider retiring the (independent) “model” graphic. -- zvr Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3889): https://lists.spdx.org/g/Spdx-tech/message/3889 Mute This Topic: https://lists.spdx.org/mt/75082578/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
