[Application-profiles-ig] Value Type and Value Space

Tue May 26 14:33:43 BST 2020

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>>重复在一个形状,这意味着职业perty>> 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 losePerhaps one could add a statement: :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 property :recipeInstructions must be used. Granted, 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 people want more 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 seeTo 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 -- Tom Baker <tom at tombaker.org>