Closed michmech closed 3 months ago
We will stick with pseudocode. Random IDs will be replaced by the recommended fragment IRIs Decided in meeting on 4th April
Will implement the decision once the debate on fragment IRIs has concluded.
I have removed arbitrary IDs from the pseudocode in all examples where they are unnecessary.
In the examples where IDs are necessary (for indicating relations), I have looked at replacing them with fragment identification strings as they are now defined in our section 3.2. The problem is that these strings are very long and not exactly human-readable, e.g. this:
id: example.com/entry/glasses/sense/an%20optical%20seeing%20aid
instead of this:
id: glasses-1
and in the PDF output they don’t even fit on one line sometimes. In my opinion this defeats the purpose of the pseudocode, which is to be easy for a human reader to follow.
So, I now propose that we go back on our decision to replace the IDs with fragment identification strings (in example pseudocode), and leave them as they are. This is allowed in our specification: “[s]erializations of DMLex may choose to assign arbitrary unique identifiers [...]”.
Agreed + add an explanation (second paragraphs at start of examples section) of why not fragids.
All the pseudo-code examples in section ‘A.1 Examples’, which are supposed to demonstrate the data model at a serialization-independent level, use IDs to indicate what relations point to. This is problematic because the data model doesn’t actually allow any ID properties at the model-level.
Perhaps it might be better to replace the pseudocode in this section with diagrams like in my “unofficial introduction”: https://www.lexiconista.com/dmlex/
Downside: It’s a lot of work to draw these diagrams. They cannot be generated automatically.
Upside: The diagrams really do make it clearer to human readers how the model “ticks” at model-level. People who have read the “unofficial introduction” have responded very well to them.