[Application-profiles-ig] Meeting Wednesday, August 12

Mon Aug 10 18:06:44 BST 2020

Tom, this is looking really good, and I think that even if our decisions are Beta and could change that we could very soon show our work more widely. I hope I'm not stepping on Ben's toes, but here's a snippet from one of his profiles [1]: "propertyLabel": "has lyricist agent (RDA 18.5)", "propertyURI": "http://rdaregistry.info/Elements/w/P10204", "mandatory": "false", "repeatable": "true", "type": "lookup", "remark": "http://access.rdatoolkit.org/18.5.html", "valueConstraint": { "useValuesFrom": [ "urn:ld4p:qa:names:person", "urn:ld4p:qa:names:organization" ] The valueConstraint:useValuesFrom looks to be essentially the ShEx uristem. (Ben - right?) I like the way that it is worded, and it seems that "useValuesFrom" takes only URI stems as its object. Multiple URI stems seem to be an OR. The type "lookup" is interesting. Is this something we can borrow? Also note that in general this looks much like the elements of our profile template. One difference is that literal datatypes don't seem to be distinguished further, but this may be just where they are in development, as in this date element: "propertyLabel": "has date of publication (RDA 2.8.6)", "propertyURI": "http://rdaregistry.info/Elements/m/P30011", "mandatory": "false", "repeatable": "true", "type": "literal", "remark": "http://access.rdatoolkit.org/2.8.6.html" Thanks, Ben! kc [1]https://github.com/CECSpecialistI/UWLibCatProfiles/blob/master/WAU.profile.RDA.eBook.jsonOn 8/9/20 3:40 PM, Thomas Baker wrote: >On 2020-08-09 09:12, Karen Coyle wrote:>>The main goal here is to confirm our choice of separate columns for value>>constraints and value constraint types, and then to develop a plan for>>finalizing value types, value constraints, and value constraint types. I>>have started a list of value types in use [1] which I'm sure is quite>>incomplete. I will add to it over the next few days as the thoughts come to>>me. If you can add more, please do.>>>>Reviewing how others have handled this question (and there are some>>interesting variants) it is clear that we have to define these 3 columns as>>a unit so that they work together. I'll try to provide some ideas in the>>document below [1] if I can clarify my thoughts.>>>>kc>>[1]https://hackmd.io/x4_FMJtZSE6sHMsdJDPoDQ>>Hi Karen,>>Thank you for pulling together this overview of value types [4]!>I'm curious about the Sinopia data type "string, of format URI",>和如何联系(或不)类型"object".>>You mention "three" columns about values, their constraints, and>their types, though I think a fourth may also have been proposed>specifically for RDF datatypes.>>Be that as it may, I'm currently thinking that we can handle the>value information with three columns - and in a way that also>includes the datatype URIs.>>I have described a number of patterns in the documentation for a>command-line utility I have been working on [1] -- see, in particular,>the examples under [2]. In my code and examples, I followed a>naming suggestion made, I think, by Ben (or John) and call the>columns:>>value type>constraint value>constraint type>>As several of us have been working on Python programs of various>sorts related to the DCAP model, Phil suggested that we have a call>sometime to compare notes, but of course any code we write will>depend on the decisions we make about design and about naming.>>Specifically, the section on RDF datatypes shows how I think datatype>URIs can be accommodated by just these three columns [3].>>Note that I designed the utility to allow URIs to be represented as>full URIs, as full URIs with enclosing angle brackets, or as prefixed>URIs - also for discussion...>>Talk to you all on Wednesday...!>>Tom>>[1]https://csv2shex.readthedocs.io/en/latest/>[2]https://csv2shex.readthedocs.io/en/latest/normalizations/Normalizations.html>[3]https://csv2shex.readthedocs.io/en/latest/normalizations/datatypes.html>[4]https://hackmd.io/x4_FMJtZSE6sHMsdJDPoDQ>-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet