Open VladimirAlexiev opened 2 years ago
You can use \@
instead of $
so you don't need quotes, nor custom parsers :)
Presumably, YAML-LD should not require anything specific to support -star; it should follow from the generalized support for JSON-LD representation in YAML. Being too explicit would require regular maintenance of YAML-LD to follow. Better figure out how to establish principles for representing JSON-LD in YAML without getting into each individual feature defined in JSON-LD, JSON-LD-star, or whatever else we may come up with.
@gkellogg Because YAML doesn't have the JSON restriction that keys must be strings, it offers a much more natural way to represent RDF-star data.
We all agree that the default route (JSON-LD->YAML-LD using the standard conversion JSON->YAML) is the base case (and an important one).
The default conversion will make YAML-LD-star example 3
.
$id:
$id: bob
age: 42
certainty: 0.8
But YAML-LD example 3F
is much nicer (easier on the eyes and easier to understand):
{$id: bob, age: 42}: {certainty: 0.8}
So Gregg, do you vote for or against this UCR?
That certainly is an interesting capability, but also contradicts #8 and other concerns about round-trip ability, at least at the syntactic level.
@gkellogg I think we should leave this issue open and write some test cases. I don't think that we will close this issue in 2022.
YAML doesn't have the JSON restriction that keys must be strings, it offers a much more natural way to represent RDF-star data.
I don't know RDF* but I think that we need proper investigation.
@ioggstream -- I realize this may seem like a quibble, but please note that while the name RDF*
was used in early drafts and discussion, it was changed to RDF-star
several months ago, for all purposes going forward.
Discussion of the thing called RDF*
(which evolved into the thing called RDF-star
) tends to devolve into issues (including regarding the name itself) which were raised on those early drafts and addressed in subsequent discussions among the RDF-star subgroup of the RDF-DEV CG.
A charter for an RDF-star
WG (which will take up the RDF-star draft spec incubated by the RDF-star subgroup) is currently under review by the W3C-AC, aiming toward a relatively near-future commencement (which would allow for such "proper investigation" as you desire).
The RDF-star WG will have a lot of work because it needs to produce an update to a whole bunch of W3C specs: https://www.w3.org/2022/06/proposed-rdf-star-wg-charter.html. However, the delta https://w3c.github.io/rdf-star/cg-spec/editors_draft.html is pretty much settled (IMHO): the WG will need to take care of a whole lot of important details, but I don't expect any surprises at the conceptual level.
https://github.com/w3c/rdf-star-wg/issues/4#issuecomment-1431763996 :
Note that the JSON-LD group will likely end up publishing JSON-LD12, JSON-LD12-API, and JSON-LD12-FRAMING eventually.
- [ ] Should there be a
SPARQL12-RESULTS-JSONLD
?- [ ] Should there be a
SPARQL12-RESULTS-CSVW
?- [ ] Should there be a
SPARQL12-RESULTS-JSONLD-CSVW
?
[ ] Should there be a SPARQL12-RESULTS-YAMLLD
[ ] Should there be a SPARQL12-RESULTS-CSVW
?
[ ] Should there be a SPARQL12-RESULTS-YAMLLD-CSVW
?
I guess there should be SPARQL12-RESULTS-YAMLLD
(for CONSTRUCT results).
As for the CSVW
variants, I asked in https://github.com/w3c/rdf-star-wg/issues/4
As an information architect. I want to be able to represent embedded triples and annotations. So that I can reap the benefits of RDF-star in YAML (YAML-LD-star).
Given the JSON-LD-star effort https://json-ld.github.io/json-ld-star/, I think YAML-LD should support the same.
Examples from that spec can be translated to YAML in a straight-forward way. Notes:
$
instead of@
to avoid quotesTurtle-star example 3
YAML-LD-star example 3:
YAML-LD-star example 4:
Turtle-star example 5
YAML-LD-star example 5:
Turtle-star example 6
YAML-LD-star example 6
Turtle-star example 7
YAML-LD-star example 7
But there is a more YAMLish way to represent these examples: In YAML, keys may be arbitrary nodes, so example 3 can be represented like this in flow style: YAML-LD example 3F:
And like this in block style: YAML-LD example 3B:
YAML-LD example 7F: