[Application-profiles-ig] Clarifications needed, was Re: Value Type and Value Space

Thu May 28 15:05:12 BST 2020

Hello all We could continue discussing this point by point, but I think that we may be somewhat at cross-purposes. I think there are a few points we could usefully clarify before continuing with the details. 1, what is the scope of this work? It's fine to focus on simple cases, but how simple? Specifying an application profile as a simple list of terms is trivial, and Tom is probably be right that at some point it will be necessary to use ShEx. But where is the boundary of our scope? Specifically, is an application profile like the Google Recipes profile of schema.org in scope? If it is, then the complex "either/or" constraints that we were discussing are ones we need to be able express. 2, where is the consideration of ease of implementation? For example, the ease of translating a list of values in a CSV cell for Value Space into a list of valid values to check against (e.g. a shex Value Set) is preferable to parsing and matching values from different columns in several rows For example, identifying what shape to try to validate a description against is easier when there is a single cell to look at for what type of resource a shape relates to, rather than looking through all statements in a shape for one that relates to type. 3, what are we talking about? I fully understand that defining terms is an iterative process that runs alongside building prototypes, and that the latter is much more fun, but it's really not worth getting too far in to discussing what is and isn't a valid value for a cell without defining what the cell is about. In the present case, I'll note that "Value Type" and "Value Space" seem to map to "Literal datatype" "Node kind" "Value set" and "value shape" in ShEx, and without further definition it's kind of arbitrary which get munged together. All the best, Phil. On 26/05/2020 14:33, Thomas Baker wrote: >On 2020-05-26 12:14, Phil Barker wrote:>>>For Line 23, could one not perhaps simply repeat:>>>>>>:recipeInstructions Entity @HowToStep n n>>>:recipeInstructions Entity @HowToSection n n>>>:recipeInstructions xsd:string n n>>>>>>The CSV guidelines could say that when a property is>>>repeated within a shape, this means that the property>>>can be used with "this value", "that value", or the>>>"other value". This would sacrifice the notion that>>>:recipeInstructions _must_ appear in the data>>>(mandatory = "y"),>>This is a vital piece of information that I am not willing to lose>也许我们可以添加一个声明:>>:recipeInstructions y n>:recipeInstructions Entity @HowToStep n n>:recipeInstructions Entity @HowToSection n n>:recipeInstructions xsd:string n n>>A bit ugly, but I think it conveys the notion that the>属性:recipeInstructions必须被使用。授予, it>wouldn't convey the notion that the value could _not_ be>a URI. But I strongly feel that we need to clearly state>some simple assumptions for the tabular format. If>人们希望铁道部e expressivity, and they understand>logical constructions more complex than simply "may have>this" and "may have that", then they really should be>getting used to a more expressive language such as ShEx.>>>>but any other option I see would>>>hit up against the limits of a CSV format that we hope>>>will be both simple and intuitive (for example, adding>>>a column that attaches "mandatory" not just to a>>>statement, but additionally to a property).>>Yes, having multiple entries in the Value Space column is the simplest most>>intuitive solution I can see>To me,>>@HowToStep @HowToSection xsd:string>>is not intuitive as a value space - i.e., an enumerated>list of possible values:>>* 'xsd:string' is not a value (at least, not here), but>the datatype of a literal value.>>* The table, therefore, does not express the notion that>(at least one of) the members of this value list are>literals.>>* @HowToStep and @HowToSection are values, but if the>algorithm treats anything in the CSV starting with '@'>as an Entity Shape ID, would a value type of>"Entity" ever really be needed by transform scripts?>>>>5. In general, if there is a value (or value list) in the>>>Value Space column, should it not always have a Value>>>Type?>>Probably. The gaps are where I wasn't sure what the value type should be. I>>think in some cases it should be ENTITY and in others ANY might be the only>>option.>If a profile can consist simply of a list of properties,>then neither Value Type or Value Space are required.>>One might want to specify:>* A value space without a corresponding value type (e.g.,>the single fixed literal "DCAT" stands on its own>and would not necessarily need to be validated as a>literal).>>* A value type without a corresponding value space ("URI",>"Literal").>>However, if more complex value spaces (Literal-, URI-, or>Mixed-Picklists) were allowed, with no information about>type, then transform scripts would have to infer types>from how the strings were constructed, e.g.: "strings>starting with '@' are Entity Shape IDs". That would seem>brittle.>>Tom>-- Phil Barker <http://people.pjjk.net/phil>.http://people.pjjk.net/philCETIS 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. -- Phil Barker <http://people.pjjk.net/phil>.http://people.pjjk.net/philCETIS 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/20200528/ebcdaf8f/attachment.htm>