[Application-profiles-ig] Our element definitions

Wed Mar 18 12:57:17 GMT 2020

All Re the recording/presentation of cardinality: The RDA community is currently using two columns, for minimum and maximum occurrence. This is just Tom's single column split into two, but it is much easier to explain to profile developers and users, neither group being technical. The main problem I see with Tom's suggestion is that 'cardinality' in a relationship does not mean the same thing, although it is conventionally expressed in a similar way; e.g. "1:n" meaning 'one to many'; this would lead to much confusion unless a) there is clear documentation and b) somebody reads it. Cheers Gordon Gordon Dunsire RDA Technical Team Liaison Officer On Wed, Mar 18, 2020 at 10:33 AM Phil Barker <phil.barker at pjjk.co.uk> wrote: >>On 17/03/2020 14:05, Thomas Baker wrote:>>在结婚,2020年3月04 09:23:13AM -0800,Karen Coyle wrote:>>I took an action to begin creating definitions for the elements that>we have used so far in the simple application profile template. I>have created a document in the github repo:>https://github.com/dcmi/dcap/blob/master/simple.md>>The starter set you propose is: Entity, Entity_label,>Property, Property_label, Mandatory, Repeatable,>Value_type, Value, Annotation.>>However, I'm wondering if we should distinguish>underlying concepts:>>Entity - a resource being described>>I would like to push for this definition to be made more specific to the>type of resources being described in an application profile, to try to>express that difficult level of "meta-ness". Everything hangs on this term,>and yet this definition seems to me to boil down to "Something - the thing".>>Property - an attribute of the resource being described>Value - the specific content of the attribute>>I think it might be clearer, or at least easier to cross-reference, if>references to previous terms were made using their names rather than their>definitions. So:>>Property - an attribute of an entity>>Value - the specific content of a property>>from the "elements" of the simple profile model:>>Entity_ID - an identifier for a resource being described>Entity_label - a human-readable text representing the resource being described>Property_ID - identifier of a property used to describe the resource>Property_label - a human-readable text representing the property>Cardinality - (see below) - the allowable number of statements using a given property with a given value>Value_type - data type of the value in the instance data for the related property>Value_constraint - a further constraint on the value>Annotation - free-form comments about the statement>>>I decided to go with the second set>which spells out mandatory and repeatable (as opposed to a single>element for cardinality).>>I'm in favor of a single-element cardinality if we could>promote a simple convention with a short explanation of>how it maps to "mandatory" and "repeatable", e.g.:>>"1">* statement must be present ("mandatory")>* statement is not repeatable>>"1..3">* statement is mandatory>* statement is repeatable up to three times>>“1 . . 1”>* statement is mandatory>* statement is repeatable an arbitrary number of times>>"0..1">* statement is not mandatory>* statement is not repeatable>>"0..-1">* statement is not mandatory>* statement is repeatable an arbitrary number of times>>Tom>>>-->>Phil Barker <http://people.pjjk.net/phil>.http://people.pjjk.net/phil>CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for>innovation in education technology.>PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning;>information systems for education.>>CETIS is a co-operative limited liability partnership, registered in>England number OC399090>PJJK Limited is registered in Scotland as a private limited company,>number SC569282.>-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.www.voudr.com/pipermail/application-profiles-ig/attachments/20200318/383ecdf8/attachment.htm>