Gary observed that when using RDF serialization, reasoning about relationships is significantly more difficult than reasoning about properties. But that is not a serialization problem, it is just a symptom of a model problem that applies to all serializations.
The most basic question a logical model must answer is: "Does an Element have a well-defined value?", or "Given an Element, what is its value?" If an Element does not have a fixed value, then it is not hashable, and we agreed long ago that Elements are immutable. The logical model must make it possible to answer the question "Does Package X CONTAIN File Y" regardless of serialization. If Microsoft creates Package Element X and defines it to contain File Elements 1, 2, 3, and Acme creates a Relationship Element saying Microsoft's Package Element X CONTAINS File Element 4, it is not a valid question to ask "Does Package X CONTAIN File 4?" The question doesn't make sense and cannot be reasoned about. The only valid questions are "Does Microsoft's *description* of Package X at 15:34 on Tuesday contain File 4", and "Does Acme's *description* of Package X at 19:23 on Wednesday contain File 4". The answer to the first is a definite No, and to the second a definite Yes. Microsoft can create various Elements describing Package X at various times with different contained files. One Package Element can list Files 1, 2 and be marked "incomplete", but that is a different Element from one that lists Files 1, 2, and 3 whether marked "incomplete" or not. So using properties as syntactic sugar for relationships is valid ONLY when the relationship and its "from" Package Element were minted together, i.e. have the identical creation info. Relationships created 1 second after the Package are not syntactic sugar for properties of that Package, they could only be sugar for properties of a different Package Element created 1 second after the first. The Package Element IRI must conceptually depend on the package's major/minor/patch number, commit ID etc., if the files contained in the package are different. So I would say it's a best practice to NOT duplicate properties with relationships, because allowing them requires desugaring relationships into properties based on identical creation info. If the practice isn't forbidden you'll always have to deal with explaining "Acme's description of Microsoft's package X as it existed at this point in the build chain". Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4309): https://lists.spdx.org/g/Spdx-tech/message/4309 Mute This Topic: https://lists.spdx.org/mt/88532578/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
