Short, labeled EXID-TYPE #307
Conversation
Resolves #177 by adding extTag option for EXID.TYPE payload Resolves #23 by adding suggeted labels for all documented extTags, including EXID.TYPEs but also extension structures. Because the labels in one dataset could differ from those suggested in official documentation, also clarifies that in-dataset labels are user-preference suggestions.
| @@ -317,6 +317,27 @@ where: | |||
|
|
|||
| The URI for the `MediaType` data type is `dcat:mediaType`. | |||
|
|
|||
| ## Shortened URI | |||
|
|
|||
| A URI, possibly shorted and documented using a [documented extension tag](#extension-tags). | |||
There was a problem hiding this comment.
| A URI, possibly shorted and documented using a [documented extension tag](#extension-tags). | |
| A URI, possibly shortened and documented using a [documented extension tag](#extension-tags). |
There was a problem hiding this comment.
I am not shure whether this solution leads to a way without extension tags in next minor/major. As the implementation in applications is not easy (so far they can build the complete link to the EXID directly), I would prefer a solution which remains very similar in following versions of the standard. Is there any idea how a solution without extension tags could work?
The proposed solution would work, but as the size of files is not very limiting, I see too much work for implementation compared to the temporary result.
| * `URI` is defined in [STD 66](https://www.rfc-editor.org/info/std66) section 3 | ||
| as what is commonly called an "absolute URI"; notably, it always includes a colon. | ||
|
|
||
| * Any `extTag` used shall be documented in the [schema] as a [documented extension tag](#extension-tags). |
There was a problem hiding this comment.
With the pandoc, the tool used to render this markdown, [schema] will be automatically interpreted as [schema](#schema). I'm fine with replacing it with gfm-compatible markdown or leaving as is
There was a problem hiding this comment.
github doesn't render [schema] as a link so would recommend replacing it.
dthaler
requested review from
clarkegj,
gibsongk,
jamestanner45,
albertemmerich and
lynchrs3
|
@tychonievich PR needs to be rebased to resolve conflicts |
| +3 LABEL <Text> {0:M} g7:LABEL | ||
| +4 LANG <Language> {0:1} g7:LANG |
There was a problem hiding this comment.
Shouldn't this label be in the YAML file (where it already exists)?
|
|
||
| A recommended short label to use in displaying information described by the superstructure to the user. | ||
| Multiple labels may be provided for the same superstructure. | ||
| As with other structures, those with the same qualifying substructures (such as `g7:LANG`) are in user preference order. |
There was a problem hiding this comment.
What does it mean to have a non-preferred label?
Resolves #177 by adding extTag option for EXID.TYPE payload
Resolves #23 by adding suggeted labels for all documented extTags, including EXID.TYPEs but also extension structures. Because the labels in one dataset could differ from those suggested in official documentation, also clarifies that in-dataset labels are user-preference suggestions.