[Application-profiles-ig] Our element definitions

Thu Mar 19 17:03:57 GMT 2020

On 3/19/20 9:05 AM, RDA Technical WG Chair wrote: >How important is it to check the cardinality specified in a profile with>what is specified in the source vocabulary? Simpler: is it a problem if>the minimum occurrence in a profile is less than the minimum occurrence>在源元素/属性的本体?如果the answer is yes, is>there a syntax for interoperability, for matching cardinality numbers by>machine?This is the $64M question, and I haven't seen anyone with an actionable solution. To back up a bit, there is the big question of validating any vocabulary reuse with its base definition, and that includes domains and ranges (for RDF), term definitions, and sub- and super-classes. We always say that reuse of vocabulary terms should be (must be?) consistent with its original definitions, but "consistent" needs a much clearer definition, and perhaps the rules could be different for terms defined in XML Schema and those defined in RDF. (Haven't thought that through.) Along with validation, there is the question of inheritance. There are communities struggling with profiles of profiles and whether a profile of a profile "inherits" the definitions and constraints of its up-stream profile - and if it does, what is the obligation of applications to read the up-stream profile and include that data in its processing? If a profile has term X with cardinality "mandatory/not repeatable" can a profile based on that profile merely include the term and the cardinality will be assumed to be the same? And, addressing Gordon's question, what is the obligation of applications to validate profiles against the base vocabulary or profile? We aren't the only ones that do not have answers to these questions. Up until now we've relied on the humans creating profiles to avoid creating inconsistencies. 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! kc -- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet