Hi David, Since you mention: * I think an ontology that defines relationship as an Element is flawed; and * it makes my head spin to think that annotations can have annotations
Let me propose a thought experiment to try to shed some light. Consider renaming some things, so that “Element” becomes “Object” (in an object-oriented-programming way, i.e., a very base class) and “Annotation” becomes “Comment”. We want “Relationships” to be Objects, so that they can have names (identifiers), and that we can record information about who created them and when, etc. etc. And we want Comments to also be Objects for the same reasons. And we also want to be able to comment on anything (which means attach a Comment to anything, any Object). Yes, that means that I might want to comment on a comment. Does this help? -- zvr From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Tuesday, 15 June, 2021 20:44 To: Sean Barnum <[email protected]> Cc: Gary O'Neall <[email protected]>; SPDX-list <[email protected]> Subject: Re: [EXT] Re: [spdx-tech] Diagrams and documents Sean, I'm not sure I fully grok the distinction between "native" and "non-native lossless", but I definitely agree that many "information models" correspond to a single ontology, otherwise there would be no need for them. Information model in my vocabulary is a "technology-agnostic serialization model" and "information" is precisely the entropy defined by information theory. In that vocabulary "lossy information model" is an oxymoron, because the information model is the definition of what you are communicating (as opposed to the insignificant data used to format that information for transmission or storage). Any lossy data instance is not a serialization of the IM, but a view of it. Irrespective of information modeling, I think an ontology that defines relationship as an Element is flawed. Of course I am blind to my own biases :-), but is there any use case for saying A is related to B by relationship R, and R is related to C in a way that can't be expressed in terms of C's relationship to A and B? As an example, for a relationship: "A is the biological parent of B", In ontology X, A has property "biological child: B" can be losslessly transformed to B has property "biological parent: A" In ontology Y, relationship is an element equivalent to A and B, "biological child" could have a parent "child" that also includes container relationships Is there any real use case for ontology Y, or is it equally (losslessly) expressive to use ontology X where "biological child" and "contained item" are elements that could themselves have "is-a" property relationship to a "child" element? I definitely do not think the ontology should be biased toward particular serializations. But independently of serialization, it makes my head spin to think that annotations can have annotations or that an annotation can have a relationship to a relationship. If there is a genuine need, fine, but as they say, extraordinary claims require extraordinary proof. That kind of complexity has a cost, it shouldn't be included just because it's possible. Dave On Tue, Jun 15, 2021 at 10:58 AM Sean Barnum <[email protected]<mailto:[email protected]>> wrote: I agree with the value of thinking through information implementation models as part of the development of standardized knowledge models (ontologies) for two purposes: 1) to vet the knowledge model as possible to implement (in other words just a proof of concept), 2) to potentially provide a reference information implementation model for any adopters looking for something off the shelf that has been thought through. I will caveat strongly that we should avoid the temptation for any information implementation model to bias the knowledge model. If it uncovers underlying issues then they should be addressed but the structure of any particular information implementation model should not bias the knowledge model purely to optimize for the information implementation model. Any information implementation model is only one possible information implementation model. Even a provided reference information implementation model is not THE model for the use of the standard. It is only one option. One of the key objectives of any knowledge model standardization effort is to enable consistency of knowledge/information across different potential information implementation models. I know I am likely stating the obvious but I have found in the past that this point can get lost in the race to implementing real world solutions. Sean Barnum C – 703-473-8262 [email protected]<mailto:[email protected]> We are here to change the world! [signature_1388200754]<https://www.facebook.com/MITREcorp>[signature_1442303485]<https://www.linkedin.com/company/mitre>[signature_245889441]<https://twitter.com/MITREcorp>[signature_984325223]<https://www.youtube.com/user/mitrecorp>[signature_929545762]<https://plus.google.com/+MitreOrgFFRDCs/posts> [signature_1845422085]<http://www.mitre.org/> From: <[email protected]<mailto:[email protected]>> on behalf of Gary O'Neall <[email protected]<mailto:[email protected]>> Organization: Source Auditor Inc. Date: Wednesday, June 9, 2021 at 12:19 PM To: 'David Kemp' <[email protected]<mailto:[email protected]>>, 'SPDX-list' <[email protected]<mailto:[email protected]>> Subject: [EXT] Re: [spdx-tech] Diagrams and documents Hi Dave, I agree with your point on the challenge we are leaving up to implementers. I am also concerned that if we don’t understand how the more general model could be implemented, we may end up finding fundamental flaws in the model late in the game. In my experience, it is very common to change the model after discovering challenges during implementation. Having an information model developed in parallel would be helpful in my opinion. Would it be possible to generate the information model from the markdown template Alexios is working on? If not, would it be feasible to add in enough information in markdown to make it possible to generate the information model? Regards, Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of David Kemp Sent: Tuesday, June 8, 2021 12:52 PM To: SPDX-list <[email protected]<mailto:[email protected]>> Subject: [spdx-tech] Diagrams and documents All, On the call Sean mentioned, almost as an afterthought, a distinction between UML class diagrams and the notation used in the spdx3 diagram. That has been bothering me for a while, as described in the attached note. We have discussed things like optimization (types don't necessarily have to contain their properties if those properties could be inferred from elsewhere), but understanding, documenting, and coding how to infer or inherit missing values is a big ask of software developers. I played a bit with information modeling at the April NTIA plugfest, but I believe it could play a role in specifying an implementable structure for SPDX3 documents. More information on the relationship between class (or knowledge) models and information models is available in the introduction section of the JADN spec https://www.oasis-open.org/committees/document.php?document_id=68701. The SPDX 3 diagram and its accompanying information model could evolve in parallel, making developers' lives easier. Regards, Dave Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva 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 (#4083): https://lists.spdx.org/g/Spdx-tech/message/4083 Mute This Topic: https://lists.spdx.org/mt/83557632/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
