Issue 537 UI widgets #572
Issue 537 UI widgets #572
Conversation
|
Note that accessibility review will probably advise us to replace |
| <p> | ||
| In this example we have used a <code>sh:values</code> rule to infer the values of the first column. | ||
| In this case, the values are simply pointing back to the focus node of each row, using <code>sh:this</code>. | ||
| Note that <code>dash:applicableToClass</code> or <code>sh:targetClass</code> are needed to get this inference correctly. |
|
|
||
| ex:ConceptTableShape | ||
| a sh:NodeShape ; | ||
| dash:applicableToClass skos:Concept ; |
| sh:path skos:altLabel ; | ||
| sh:description "The third column shows the alternative labels." ; | ||
| sh:name "alt labels" ; | ||
| sh:or dash:StringOrLangString ; |
| 0 if the property is marked <code>sh:singleLine true</code>. | ||
| 20 if the value is an <code>xsd:string</code> literal and <code>sh:singleLine false</code>. | ||
| 5 if the value is an <code>xsd:string</code> literal. | ||
| 2 if the property has <code>xsd:string</code> among the permissible datatypes. | ||
| <code>null</code> if the property has a custom datatype (not from xsd or rdf namespaces but for example <code>geo:wktLiteral</code>). | ||
| 0 otherwise. |
There was a problem hiding this comment.
Such long lists may be better as lists (I recommend <ul> to prevent confusion between a numbered item in an <ol> and the score discussed in that item. I think <ol> is fine, since these are all disjoint, and can be presented in any order.), as the clarity of this manually linebroken source does not persist when all these lines fold into a single wrapping line. Such <ul> or <ol> lists should probably be used throughout, whenever there are multiple Score: lines. (This is one argument to consistently wrap running prose at 80 chars in the source, and not at indefinite "sentence" or "thought" breaks — so source writers have some sense of how the content will be rendered for later readers.)
| 0 if the property is marked <code>sh:singleLine true</code>. | |
| 20 if the value is an <code>xsd:string</code> literal and <code>sh:singleLine false</code>. | |
| 5 if the value is an <code>xsd:string</code> literal. | |
| 2 if the property has <code>xsd:string</code> among the permissible datatypes. | |
| <code>null</code> if the property has a custom datatype (not from xsd or rdf namespaces but for example <code>geo:wktLiteral</code>). | |
| 0 otherwise. | |
| 0 if the property is marked <code>sh:singleLine true</code>. | |
| 20 if the value is an <code>xsd:string</code> literal and <code>sh:singleLine false</code>. | |
| 5 if the value is an <code>xsd:string</code> literal. | |
| 2 if the property has <code>xsd:string</code> among the permissible datatypes. | |
| <code>null</code> if the property has a custom datatype (not from <code>xsd:</code> nor <code>rdf:</code> namespaces, but, for example, <code>geo:wktLiteral</code>). | |
| 0 otherwise. |
| </p> | ||
| <p> | ||
| <b>Rendering:</b> | ||
| a multi-line text area to enter the value of a literal and a drop-down to select a language. |
There was a problem hiding this comment.
What happens when a new language code is minted by the appropriate standards body? Or when setting/rendering a custom language is desired?
There was a problem hiding this comment.
I propose creating a separate section for language handling in the specification. How do different sets of languages (full ISO list, browser languages, configured languages, sh:languageIn) play together?
| <h4>shui:TextFieldWithLangEditor</h4> | ||
| <p> | ||
| <b>Score:</b> | ||
| 11 if the value is an <code>rdf:langString</code> literal or the property permits either (both) <code>rdf:langString</code> or <code>xsd:string</code>. |
There was a problem hiding this comment.
Permitting either means it permits one datatype at a time, which I think is correct. Permitting both means it permits two datatypes at the same time, which I think is incorrect, as I think these are disjoint types.
| 11 if the value is an <code>rdf:langString</code> literal or the property permits either (both) <code>rdf:langString</code> or <code>xsd:string</code>. | |
| 11 if the value is an <code>rdf:langString</code> literal or the property permits either <code>rdf:langString</code> or <code>xsd:string</code>. |
There was a problem hiding this comment.
RDF 1.2 also has rdf:dirLangString in addition to rdf:langString
Either include each time (spoec detail style), or say that rdf:dirLangString can be accepted where rdf:dirLangString occurs.
There was a problem hiding this comment.
@afs —
say that
rdf:dirLangStringcan be accepted whererdf:dirLangStringoccurs
I'm pretty sure one of the two rdf:dirLangString above ought to be rdf:langString, but I'm sorry to say I'm not sure which.
Co-authored-by: Ieben Smessaert <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]> Co-authored-by: Edmond Chuc <[email protected]>
This PR adds the widgets from datashapes.org. The namespace was adapted, and other minor changes were made to align it with the other SHACL specifications.
The selection of widgets and the details in the widget should be handled in a separate PR. This is an initial starting point so that other PRs can refer to widgets.
dash:applicableToClass and dash:rootClass was kept as there is no matching SHACL property. The dash namespaces should be easier to notice when we work on the details.
Closes 537