All, we're getting into interconnected moving parts now, but I'll try to offer a perspective on just one of William's questions:
* What about use cases where we want to serialize a graph of elements > from different documents into a single physical stream (e.g. wanting to put > in a single JSON API response, or collapse into a single physical JSON file > for ease of transfer into an air-gapped environment, etc.)? Axioms: 1) Every Element in the SPDXv3 logical model can stand on its own without reference to any other Element 2) We've agreed that a logical Element (an IRI and all of it's property values) are immutable once minted. 3) No two Elements can be minted by a creator at the exact same time. Sean mentioned an API use case of GitHub returning a list of all accounts created in the last 6 hours. If the GitHub API used Elements it could return the answer in (at least) two formats: a) a set of 57 individual Elements, one for each account b) a Collection Element that is composed of 57 additional "account" Elements I would call the first thing a bundle or non-contextual collection. The 57 Elements are minted by GitHub but have different creation instants. The second thing is a contextual collection because even if the accounts have nothing else in common, they are peers in an Element with the description "accounts created between 0900 and 1500 on mm/dd/yy", a "minter" of GitHub, and a single creation instant. Although the accounts are created at different times, they are composed into a single collection before the collection is minted, and each Element in a collection has the identical creation info. Once the API recipient has received account info from GitHub as individual Elements, a Collection Element, or a non-Element API value, that recipient can then mint individual or Collection Elements, with new IRIs, the recipient as the minter, and new creation instant(s). So in my mind, "Non-ccontextual Collection" is not an Element, because a Collection Element provides at a minimum the context of the Collection Element to its member Elements. I propose that, whatever happens to Document, the logical model includes a "Bundle" class that is not a subclass of Element. I'd prefer that that class not be called Document, but I don't care as much about the name as about the fact that it is not an Element. Dave P.S. Other questions chain from this, but those are separate topics. For example, a collection may include references to Elements minted at a different time and different creator, and that collection may be serialized with copies of the referenced Element values. Also, although "mint" and "forge" may be the same, "creator" / "issuer" / "minter" are unambiguously better names than "forger" :-). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4221): https://lists.spdx.org/g/Spdx-tech/message/4221 Mute This Topic: https://lists.spdx.org/mt/86611379/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
