Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

RDF WG Review: Eric Prud'hommeaux #136

Closed
msporny opened this Issue · 3 comments

2 participants

@msporny
Owner

Review by Eric Prud'hommeaux of RDF WG:

examining http://json-ld.org/spec/latest/json-ld-syntax/ 15 June 2012

link to http://json-ld.org/spec/latest/json-ld-syntax/diff-20120522.html => 404

Last to paragraphs of SOTD repeated after TOC.

refs http://www.ietf.org/rfc/rfc4627.txt, which i recall being out of synch with e.g. http://www.json.org/.
can we reference HTML form http://tools.ietf.org/html/rfc4627? Others have made that leap of faith.

§1 ¶1
s/you/one/ # personal taste.

§1.1 ¶7
s/collection of values/sequence of zero or more values/ # match rfc4627 §1 ¶5.

§1.1 ¶8
s/Unicode (UTF-8) characters/Unicode characters/ # "UTF-8" characters ambiguous between codepoints and bytes.

§1.1 ¶11
NULL @context requires detailed forward understanding.
perhaps add the text "@context is defined below"?
or maybe swap §1.1 and §1.2 (no contraindications that I saw).

§1.2 ¶3
s/@graph Used to explicitly express/@graph Used to explicitly label/?
no forward ref to definition (others have such a ref).

§1.3 should be in SOTD (in WD)

§2 ¶6 Zero Edits means it's like GRDDL for JSON -- neato

§3.1 ¶2 overloading of "objects". is there any graceful way to disambiguate without relying on hrefs?

§3.1 ¶3,5 RDF very practical definitions of subject and object, but slightly at odds with RDF defns which cast subjects and objects in terms of their role in a triple.

§3.1 ¶4 "A subject should be labeled with an IRI" could push folks to inventing identifiers they won't/can't honor or reproduce.

§3.1 ¶8 s/the linked data graph/a linked data graph/ ?

§3.1 ¶9 RDF properties MUST be IRIs

§3.1 ¶10 "dereferencable to a Linked Data document" - is RDFS in RDF/XML a "Linked Data document"?

@gkellogg gkellogg was assigned
@gkellogg
Owner

Review by Eric Prud'hommeaux of RDF WG:

examining http://json-ld.org/spec/latest/json-ld-syntax/ 15 June 2012

link to http://json-ld.org/spec/latest/json-ld-syntax/diff-20120522.html => 404

Diffs are only available when published as an ED, not in the live document. This will be updated with the final CG publication.

Last to paragraphs of SOTD repeated after TOC.

Seems to have been a ReSpec bug. Updating to 3.1.3 fixed it.

refs http://www.ietf.org/rfc/rfc4627.txt, which i recall being out of synch with e.g. http://www.json.org/.
can we reference HTML form http://tools.ietf.org/html/rfc4627? Others have made that leap of faith.

This is boilerplate from ReSpec. I could override it, but probably the place to make the change is in the ReSpec repo. All RFC references are to the .txt versions; it should be a coordinated change.

That said, if the group feels strongly about this, we can override the BibRef in the document to point to the HTML version of the spec.

§1 ¶1
s/you/one/ # personal taste.

It's more extensive to that, and arguably looks stilted. The first-person style seems more approachable.

§1.1 ¶7
s/collection of values/sequence of zero or more values/ # match rfc4627 §1 ¶5.

Done.

§1.1 ¶8
s/Unicode (UTF-8) characters/Unicode characters/ # "UTF-8" characters ambiguous between codepoints and bytes.

Done.

§1.1 ¶11
NULL @context requires detailed forward understanding.
perhaps add the text "@context is defined below"?
or maybe swap §1.1 and §1.2 (no contraindications that I saw).

There's aready a link to the context definition in the same sentence.

§1.2 ¶3
s/@graph Used to explicitly express/@graph Used to explicitly label/?

Done.

no forward ref to definition (others have such a ref).

Added ref to §4.9 Named Graphs.

§1.3 should be in SOTD (in WD)

Done.

§2 ¶6 Zero Edits means it's like GRDDL for JSON -- neato

§3.1 ¶2 overloading of "objects". is there any graceful way to disambiguate without relying on hrefs?

I did a pass through, but it seems that we consistently use the term JSON object to refer to the {} representation, and object for the RDF sense. I cleaned up a couple of places where it could have been ambigious.

§3.1 ¶3,5 RDF very practical definitions of subject and object, but slightly at odds with RDF defns which cast subjects and objects in terms of their role in a triple.

I think this definition provides a better theoretic definition for subject and object, but I added an issue marker to track your comment.

§3.1 ¶4 "A subject should be labeled with an IRI" could push folks to inventing identifiers they won't/can't honor or reproduce.

This is wrapped up in the definition of linked data and the role of BNodes. No change, right now.

§3.1 ¶8 s/the linked data graph/a linked data graph/ ?

Done.

§3.1 ¶9 RDF properties MUST be IRIs

Add issue marker. When used as just JSON-LD, this is not unreasonable; it only becomes an issue (and could raise an exception) when transformed to RDF.

§3.1 ¶10 "dereferencable to a Linked Data document" - is RDFS in RDF/XML a "Linked Data document"?

Yes. But typically this would be understood to be a JSON-LD document. For such developers, I think it would also be reasonable to link to an HTML+RDFa document. The idea is that they should link to something that describes itself; content negotiation can be used to obtain a prefered representation.

Thanks for your feedback!

@gkellogg
Owner

Hmm. The SOTD still has paragraphs repeated after the TOC. I updated ReSpec, which I thought was the culprit, but it still seems to be showing up.

@gkellogg gkellogg closed this
@gkellogg
Owner

Just tagging @ericprud on this response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.