[Application-profiles-ig] Our element definitions

Thu Mar 19 13:31:18 GMT 2020

Thanks, Phil. Note also that we can make our definitions more ample. There seems to be a general tendency to be very terse in definitions but I don't see the necessity. I'll try to incorporate these into the definitions document [1]. If we have particular problems we can create github issues for a longer discussion. Also, I am hoping to address some of these in an upcoming meeting. kc On 3/18/20 3:33 AM, Phil Barker 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.>-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet