(应用程序概要文件s-ig] Profiles should be (by default) "stand-alone"

Sat Apr 11 17:22:44 BST 2020

On Thu, 19 Mar 2020, Karen wrote: >...We've also in general created profiles as>"stand-alone" thus avoiding having applications go up-stream to>complete the profile. These are huge open questions. If anyone has>answers, please don't keep them to yourself!It is sometimes asserted that profiles can "inherit" information (e.g., cardinality constraints) from each other (e.g., [1]). However, I am not aware that the notion of inheritance among profiles has ever been formalized in a general sense, and I suspect that trying to do so would lead down a rabbit hole. Even within the paradigm of object-oriented programming, there are different models of inheritance, especially around "multiple" inheritance, about which the designers of various O-O programming languages like Java, Scala, C++, Python, and Ruby have make their various (and all defensible!) design choices. But while alot of programmers may look at application profiles through the lens of O-O programming, which is fine and of course practical, O-O is not a paradigm we can or should pretend to adopt for our own simple model. Within specific contexts (like RDA or DCAT), the creators of application profiles may want to formulate guidelines for how profiles relate to other profiles within families of related profiles. I think this is fine, but it would be a thankless task to seek widespread consensus for guidelines about "families of profiles" for the Metadata World as a whole. In the early 2000s we used to say: "vocabularies (or namespaces) define, and profiles re-use". The distinction was clear, and there was even discussion about whether it was a good idea to mix profiles and namespace declarations in a single document; it was generally frowned upon. While there was some discussion at DC-2006 about profile "extensions", this merely served to draw attention, as I recall, to how brittle profiles would become if a requirement for a specific type of dependency management were introduced. We backed away from what we saw as a slippery slope. I propose that we, in this group, say clearly that in the AP-STM model, each profile be considered by default to be stand-alone. If a particular community needs to "layer" related profiles in dependency or inheritance hierarchies, this is fine but we should consider this to be a design and implementation choice out of scope for our simple model. Tom [1]https://www.w3.org/TR/dx-prof/#Property:isInheritedFrom-- Tom Baker <tom at tombaker.org>