Thanks for following up with this, David. Actually, no headers are missing. Or, to be more accurate, the headers on RDF are always “subject – predicate – object”.
There is no distinction between the two cases you list, because the same mechanism is used to record facts about actual data (usually “instances” in OOP-parlance, like “Alice is a Person”) but also meta-data about the structure (“Person is a Class”). After all, a defined class is simply an instance of a generic “Class” class (if it makes sense written like this). For simplicity, I did not provide a complete example, but here are some triples defining the “relationships” you mention: hasGender is-a Property hasGender connects-from Person hasGender connects-to Gender isGenderOf is-a Property isGenderOf connects-from Gender isGenderOf connects-to Person hasGender is-inverse-of isGenderOf You see that “Relationships” (in your parlance) can appear on any of the three columns. All subjects, predicates, and objects are… arbitrary (and can be represented by a URI). Therefore we can represent facts about relationships, classes, instances of classes, … everything – and they are all the same! Feel free to use the established “subject / predicate / object” terminology, but know that it’s really “entity / entity / entity”; the s-o-p are simply the roles in that line. Our ontology will of course define classes and properties specific for SPDX, like Element, Attribution, hasAttribution, isAttributionOf, etc. etc. But there is nothing special in the knowledge representation (in triples in these emails) that distinguishes “Relationship” and “Categories” as you call them. -- zvr From: [email protected] <[email protected]> On Behalf Of David Kemp Sent: Thursday, 17 June, 2021 17:26 To: SPDX-list <[email protected]> Subject: Re: [spdx-tech] XML and JSON Alexios, To pull the information modeling thread a bit using your example, the names of the tuple columns are missing. If this were a spreadsheet it would look like: Entity Rel Category ------ ----- -------- Person is-a Class Alice is-a Person or: Entity Rel Entity ------ ----- ------ Person is-a Class Alice is-a Person The difference is meaningful because "Category", like "Relationship", can be enumerated in a standard like SPDX: Relationship = {1: is-a, 2: hasGender, 3: hasHairColor, ...} Category = {1: Class, 2: Person, 3: Gender, 4: Male, 5:Female, ...} while Entity cannot. Entity includes categories but also includes people. The first item in your list could be serialized in JSON as: {"entity": "Person", "rel": "is-a", "category": "Class"} (Verbose or Unfriendly JSON) ["Person", "is-a", "Class"] (Compact or Friendly JSON) ["Person", 1, 1] (Concise or Machine-optimized JSON) The information model defines that those three serializations contain the identical information, and any one can be losslessly converted to the others. If data is not constrained to a defined list, then 1) it does not optimize as well and 2) it is more difficult to reason about as knowledge. For the second column a knowledge engine needs less AI if it is given a defined list of Relationships than if it has a data lake of unconstrained strings and has to infer what they mean. The same applies to the third column if it makes sense within the problem domain. Information modeling highlights that there are alternatives, it doesn't advocate a particular answer. Dave On Wed, Jun 16, 2021 at 7:42 AM Zavras, Alexios <[email protected]<mailto:[email protected]>> wrote: [...] But remember, we are talking about knowledge representation—what we know about those people. The exact same data may be serialized as: Person is-a Class Alice is-a Person Bob is-a Person Charlie is-a Person Gender is-a Class Male is-a Gender Female is-a Gender Alice hasGender Female Bob hasGender Male Charlie hasGender Male This is simply a collection (list) of facts – and the different entities appearing therein create a graph, not a tree. To make it even more visible, the last fact may be replaced by an equivalent: Male isGenderOf Charlie [...] [https://ssl.gstatic.com/ui/v1/icons/mail/no_photo.png] ReplyForward 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 (#4088): https://lists.spdx.org/g/Spdx-tech/message/4088 Mute This Topic: https://lists.spdx.org/mt/83564830/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
