Re: JSON-LD terminology

On Aug 30, 2012, at 10:58 AM, Andy Seaborne <andy.seaborne@epimorphics.com<mailto:andy.seaborne@epimorphics.com>> wrote:

Richard's first comment included:
I think that this discussion belongs onto the WG mailing list and
shouldn't just be buried in the issue tracker, so I'm posting the
message here too.

Ditto.

I received offlist email:

On 30/08/12 18:32, Markus Lanthaler wrote:
I've created a timestamped editor's draft for the syntax and the
API spec at


http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/ED/json-ld-syntax/20120830/index.html

http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/ED/json-ld-api/20120830/index.html

@cygri <https://github.com/cygri>, @afs <https://github.com/afs> does
this address all the concerns you raised as part of this issue so
that I can close it?

—
Reply to this email directly or view it on GitHub
<https://github.com/json-ld/json-ld.org/issues/47#issuecomment-8167501>.


What are the changes within these two document that are relevant to this
discussion? (And why does it now span two documents?)  I'm not sure what
you're asking me about - checking two large docs isn't viable.

The changes (my changes anyway) principally relate to changing subject definition/reference to node definition/reference, and the cascading changes that related to. The second set of changes related to the updated definition of Linked Data as we had discussed.

You received this, as Markups was commenting on an issue. I don't think we've addressed all of the issues related to the email chain I initiated, but apparently enough to warrant a new timestamped document. There is more to do to address some of the raised concerns, but for my part, I didn't have the time to exhaustively get to all of these yet.

The issues span both syntax- and api-documents, as they both used the subject definition/reference language and had related definitions of Linked Data, I wanted to try to keep them reasonably close together.

Other recent changes include:

* 56d171de103ff9b4a314b5ee92ad6e9cbc40f1a3
Rename "nested contexts" to "scoped contexts" and remove External Contexts section

Almost all the information contained in the External Contexts section was already contained the The Context section. The only thing missing there was the scoped context example which was moved as part of this commit. Therefore I also completely removed the External Context section at the same time.

* 0f89a12f641a76145c7f37bb18c4613c09c1e561
Add note that node definitions may be partial and remove subject/predicate/object

Now, the JSON-LD Syntax specification doesn't mention subject, predicate, or object anymore.

* f1e5de44cd52802c0720bb3af293acb2b072790d
Use "property" instead of "predicate" in the API

* 8167275216ae3c161cafdec82913036e85b69b75
Rename "language tagged literal" to "language tagged string"

This is in accordance with RDF-CONCEPTS. Also fixed some broken links.


I do see (ISSUE 47 note):

"""
Note that this definition is provisional, and may be reverted to
something closer to the original depending on community feedback.
"""

so nothing has actually been decided yet?

As I said before, the changes are substansive enough that on the JSON-LD call we felt we needed more visibility from the community which helped come up with our definition of Linked Data in the first place. I think Manu was going to put something together to send out to the public-linked-json and rdf-comments lists that called this out. This is why the issue isn't closed, and the issue marker with the previous definition still exists.

[[
Note

JSON-LD allows properties to be BNodes, while RDF does not. When used as
just JSON-LD, this is not unreasonable; it only becomes an issue (and
could raise an exception) when transformed to RDF.
]]

This is an example of a change that needs to be made, but I haven't been able to get to myself, yet.

but also:
[[
An edge must be labeled with an absolute IRI, within the JSON-LD syntax,
this label is called a property.
]]

I like the note spelling out that linked data does not have to be
JSON-LD.  Are notes going to be in the final document?

I believe so, but we are invoking RDF earlier in the document than we did before, and some of the editors may have a different opinion on this. However, I believe we all agree on the principle expressed here, if not the specifics.

Gregg

Andy