You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>As a processor. I want to easily distinguish between "plain" YAML-LD and "ideomatic" YAML-LD based on the use of local tags (or similar) which may require post-parsing processing to be interpreted using the JSON-LD processig algorithms. So that more complicated processing steps can be avoided.</p>
87
87
<preclass="example">
88
88
!yaml-ld
@@ -98,6 +98,230 @@ <h4>Distinguish "plain" YAML-LD from "ideomatic" YAML-LD</h4>
There seems to be a general concensus against using any special YAML
132
+
encoding considerations in the <em>basic profile</em>.
133
+
</p>
134
+
</section>
135
+
136
+
<sectiondata-format="markdown" id="uc-11">
137
+
#### Replace $-keywords with @-keywords ([#11](https://github.com/json-ld/yaml-ld/issues/11))
138
+
139
+
As an author of YAML-LD files.
140
+
I want an ability to type keywords without quotes.
141
+
So that my authoring experience is better.
142
+
143
+
JSON-LD keywords such as `@id` and `@type` must be quoted when used as keys in YAML. Using an alternative representation such as `$id` and `$type` allows these keywords to be used without quoting.
144
+
145
+
<pclass="note">
146
+
This can largely be achieved using aliases in a context, perhaps
147
+
a standardized context.
148
+
This does not handle `@context` itself, nor keywords used within
149
+
a YAML defined context.
150
+
Alternatively, this may be handled by the <i>documentLoader</i>
151
+
</p>
152
+
</section>
153
+
154
+
<sectiondata-format="markdown" id="uc-12">
155
+
#### Convert JSON-LD to YAML-LD using standard YAML libraries ([#12](https://github.com/json-ld/yaml-ld/issues/12))
156
+
157
+
As a developer.
158
+
I want to be able to convert JSON-LD documents to YAML-LD by simply serializing the document using any standard YAML library.
159
+
So that the resulting YAML is valid YAML-LD, resolving to the same graph as the original JSON-LD.
160
+
161
+
Conversely, I would be very surprised (and annoyed) if such a simple conversion did not work.
162
+
163
+
This is why, although I do not oppose $-keywords ([#11](#uc-11)) for authoring YAML-LD from scratch, I want @-keywords to be also supported.
164
+
</section>
165
+
166
+
<sectiondata-format="markdown" id="uc-13">
167
+
#### Define anchor usage in yaml-ld ([#13](https://github.com/json-ld/yaml-ld/issues/13))
168
+
169
+
As a json-ld editor.
170
+
I want to use yaml anchors.
171
+
So that I can easily reuse content.
172
+
173
+
<divclass="note" data-format="markdown">
174
+
The specification should define:
175
+
176
+
* when it is legitimate to use anchors
177
+
* which are the expectation on anchor usage (e.g. do they represent a specific JSON-LD node or they can just be used to represent content?)
178
+
* are there any constraint on anchor usage? (e.g. the representation graph MAY / MUST NOT be a cyclic graph...)
179
+
</div>
180
+
181
+
<preclass="example">
182
+
---
183
+
- "@id": &homer http://example.org/#homer # Anchor the homer url
184
+
http://example.com/vocab#name:
185
+
- "@value": Homer
186
+
- "@id": http://example.org/#bart
187
+
http://example.com/vocab#name:
188
+
- "@value": Bart
189
+
http://example.com/vocab#parent:
190
+
- "@id": *homer # reuse the anchor instead of re-typing the homer url
191
+
- "@id": http://example.org/#lisa
192
+
http://example.com/vocab#name:
193
+
- "@value": Lisa
194
+
http://example.com/vocab#parent:
195
+
- "@id": *homer
196
+
</pre>
197
+
</section>
198
+
199
+
<sectiondata-format="markdown" id="uc-17">
200
+
#### YAML-LD datatypes (and tags for datatypes) ([#17](https://github.com/json-ld/yaml-ld/issues/17))
201
+
202
+
- RDF uses explicitly tagged literals, in particular lang strings and XSD datatypes, including infinite precision integers and decimals.
203
+
- JSON carries faithfully strings and small numbers, everything else must be represented as a string with a separate field to indicate the datatype (`@type` in JSON-LD). Eg see https://github.com/w3c/json-ld-syntax/issues/387 for the pitfalls of using large integers or decimals
204
+
- YAML can use tags to carry literals faithfully (including infinite precision, "markers" like `-.inf` and `.nan`, datetimes), and even more complex structures. One could declare "YAML schemas" with additional tags, eg to represent all XSD datatypes
205
+
206
+
Why might we want more than "string plus `@type`"?
207
+
- convenience (eg see `dc:date` below and many other examples)
208
+
- normalization (reduce/eliminate lexical vs value space differences): it seems to me easier for a processor to normalize `02022-05-18` to `2022-05-18` if tagged as `!xsd!date` rather than looking at a parallel `@type` field.
209
+
210
+
Let's collect below examples of what we could want.
211
+
212
+
---
213
+
214
+
@gkellogg in https://github.com/ietf-wg-httpapi/mediatypes/issues/8#issuecomment-1034040169
215
+
> If I were to revisit anything in the JSON-LD data model, it would be the interpretation of JSON numbers to allow for decimal values. As it is now, JSON numbers are either interpreted as integers (long) or doubles based on the range of the number. But, in JSON-LD 1.1, we use The JSON Canonicalization Scheme ([RFC8785](https://www.w3.org/TR/json-ld11/#bib-rfc8785)) as a way to represent numbers in the rdf:JSON datatype serialization, which allows for a serialization form of either integer, decimal, or double. This really only comes into play in JSON-LD when creating RDF literals from native JSON numbers (something which is generally a bad design point, but is there to allow a reasonable interpretation of native JSON forms), but could also come into play when representing those numbers in the data model, and thus in serializations to forms such as YAML.
216
+
217
+
---
218
+
219
+
@VladimirAlexiev from #2:
220
+
- [Tags](https://yaml.org/spec/1.2.2/#3212-tags) are comparable to datatypes.
221
+
- the YAML [json schema](https://yaml.org/spec/1.2.2/#102-json-schema) and [core schema](https://yaml.org/spec/1.2.2/#103-core-schema) handle string, boolean, integer, float (the latter allows things like `-.inf` and `.nan`).
222
+
- https://yaml.org/type/ handles a wider set, in particular dates and datetimes. But please note these are considered deprecated in 1.2 and are being removed in 1.3 https://github.com/yaml/yaml-spec/issues/268#issuecomment-1039000203
223
+
- Maybe we should define a YAML schema to handle more xsd datatypes?
224
+
- It should aim to eliminate problems related to the limited and non-standardized set of JSON literals. Eg the JSON number `12345678901234567890.12345` is converted to RDF literal `"12345678901234567168"^^xsd:integer` (see [jsonld playground](https://tinyurl.com/yy6xh52v))
225
+
- And could even work as a replacement of `@type`, eg
I want data modeling language(s) independent of technical artefacts
247
+
So that:
248
+
- the language is understandable to domain experts
249
+
- it can generate a variety of required technical artefacts
250
+
- all these artefacts are kept in sync, thus lowering maintenance effort
251
+
252
+
For efficient RDF modeling, you need to define multiple related artefacts:
253
+
- ontology
254
+
- shapes (SHACL (@holgerknublauch) or SHEX (@ericprud))
255
+
- diagrams and other documentation
256
+
- JSON-LD context,
257
+
- maybe JSON-LD frames,
258
+
- JSON schema or Avro schema
259
+
- API bindings and hypertext controls (HATEOAS)
260
+
- etc
261
+
262
+
Thus, many people have expressed the desire to define a unified or "technology independent" modeling language.
263
+
- See eg https://github.com/w3c-ccg/traceability-vocab/issues/296 for a brief list of modeling framework requirements
264
+
265
+
Many communities like to have a LD expression of their data, but mostly care about defining the data with JSON schema. Efforts to marry JSON Schema with JSON-LD contexts have been undertaken in:
266
+
- `w3c-ccg` @OR13 @nissimsan @msporny
267
+
- WoT: https://www.w3.org/2019/wot/json-schema, http://www.w3.org/2019/wot/hypermedia @vcharpenay, @maximelefrancois86, María Poveda Villalón
268
+
- OAS: [OpenAPI-Specification/](https://github.com/OAI/OpenAPI-Specification/), [OAS Semantic Context](https://docs.google.com/document/d/1fBRH2wtg1p_g4voNSTlHiSJmKgvfNaIsUXwPBO36RuM/edit) in particular for eGovernment APIs @ioggstream @pchampin @giorgialodi
269
+
270
+
Many polyglot frameworks are YAML-based. Examples include:
YAML-LD should not take over these modeling-framework efforts, but should show how they can be used together, show archetypical examples, and maybe make a comparison.
283
+
284
+
Even if no Modeling requirements make it into any YAML-LD spec, this git repo could serve as a "meeting place" for people working on these topics, potentially resulting in some unification.
285
+
</section>
286
+
287
+
<sectiondata-format="markdown" id="uc-31">
288
+
#### Fragment identifier ([#31](https://github.com/json-ld/yaml-ld/issues/31))
289
+
290
+
As a user.
291
+
I want a **fragment identifier specification**.
292
+
So that **I can reference specific elements of a yaml-ld**.
293
+
294
+
295
+
#### Notes
296
+
YAML fragid processing is described [here](https://www.ietf.org/archive/id/draft-ietf-httpapi-yaml-mediatypes-02.html#section-2.1-2.20.1)
297
+
298
+
Q0. Do you think that yaml processing is enough?<br/>
299
+
Q1. Do .jsonld support JSON Pointer or other referencing method?<br/>
300
+
Q2. Do we need a way to reference a specific resource via id, eg. `#id=<URI>` ? In case, this will be specific yaml-ld extension that generic yaml parsers might not support.<br/>
301
+
</section>
302
+
303
+
<sectiondata-format="markdown" id="uc-35">
304
+
#### Defining various interoperability profiles ([#35](https://github.com/json-ld/yaml-ld/issues/35))
305
+
306
+
As an Editor
307
+
I want a set of different interoperability profiles
308
+
So that I can select the YAML features that are supported by a YAML-LD implementation
309
+
310
+
## Note
311
+
312
+
For example I could define
313
+
314
+
* a BASE profile that is just JSON with YAML syntax: no anchors / alias nodes, only string keywords, only JSON datatype values, comments
315
+
* an EXTENDED profile: with anchors / alias nodes but only with a rooted directed acyclic graph
316
+
317
+
## Elements to be discussed in profiling
318
+
319
+
- [ ] data types https://github.com/json-ld/yaml-ld/pull/34/files#r912093915
0 commit comments