Gregg Kellogg: In terms of Editors Drafts - we should push out another version of the specs.

Gregg Kellogg: I think we're close to stability w/ the syntax - main thing on the board is changing @literal to @value.

Gregg Kellogg: Other than that, we may be converging on the syntax.

Niklas Lindström: I finally got around to adding support for JSON-LD in RDFExtras... complementary lib to RDFLIB in Python... doesn't bring any news issues today, but am getting a feel for the details of the spec.

Niklas Lindström: http://code.google.com/p/rdfextras/source/browse/?name=jsonld#hg%2Frdfextras

Niklas Lindström: I did notice that the tests are a bit strange, changed SPARQL to TURTLE examples... I do back-and-forth conversion - may want to look into that.

Gregg Kellogg: Is this in the source repository?

Niklas Lindström: Not yet.

Manu Sporny: Test suite looks great... we will probably keep using that... you have to implement a test runner for it?

Gregg Kellogg: Yes, one caveat is that you need SPARQL to do some comparisons... we could turn it into normalized JSON and just compare that.

Gregg Kellogg: SPARQL is only used for RDF conversion tests...

Gregg Kellogg: You could go from JSON-LD - RDF - JSON-LD - normalize and compare that, but that's a bit complicated.

Manu Sporny: Do you know if the JavaScript SPARQL implementations are fairly complete?

Gregg Kellogg: Haven't had the time to look in depth.

Niklas Lindström: Parsing JSON-LD then serializing to normalized JSON structure is complex... you don't really know where in that chain those things fail. SPARQL implementations are quite complex as well... perhaps we should look into RDF triple set comparison. There is a fairly understandable implemention of it in RDF lib.

Gregg Kellogg: I have one of those in Ruby as well... doing Jeremy Carroll's algorithm is not simple. It's important to have - triple comparison is simple to do... understandable why you can't do that for RDFa... but for JSON-LD, that may be possible.

Gregg Kellogg: The issue is that if you are serializing from RDF into JSON-LD, where you have namespaces, but you don't have terms, you can easily create CURIEs, but you'd also like to have the full coercion expressivity.

Gregg Kellogg: For example, you want to be able to say that a property is a certain datatype...

Gregg Kellogg: In my implementation, anything that can be an IRI in the key position in the context can be a CURIE or an IRI... that allows you to do useful things, where terms can have coercion properties.

Manu Sporny: Spoke with Dave Longley about it, he's for it. So am I, seems like a useful feature.

Markus Lanthaler: You could have several definitions for the same term... you could have 3 different URIs for the same term and 3 different datatypes - we'd have to specify how to merge those different definitions together.

Gregg Kellogg: my table is defined w/ IRIs as keys, so this can't happen.

Gregg Kellogg: I think that if you end up setting a term to a different IRI, the algorithms won't invoke that mapping.

Gregg Kellogg: If we split the key on a colon, you look up the prefix... you get the IRI... if it is an IRI or CURIE, you just get the term part of it.

Markus Lanthaler: Nevertheless, if you have two URIs defined, you have to figure out how to set them.

Gregg Kellogg: I don't know if we want to specify the behavior...

Niklas Lindström: I think there might be a problem here, one thing that strikes me is that we probably should that there is a precedence rule... there should probably be the possibility to define two different terms for the same IRI, but with different coercions.

Manu Sporny: I think we should kick out an error if somebody tries to set an IRI w/ the CURIE mechanism.

Niklas Lindström: I think that's fine.

Niklas Lindström: I think that we should expand CURIEs in context quickly.

Gregg Kellogg: I agree that the only time an @id should be set is when it's used as a term.

Gregg Kellogg: We should say that coercions map to the expanded version of the terms... that is what is used when we do coercion.

Markus Lanthaler: If you do that on an expanded IRI, it would prevent the use of two different terms with two different datatypes.

Markus Lanthaler: This is mainly for when you generate JSON-LD from RDF... when you automatically serialize RDF, you don't know if every property will use the same datatype.

Markus Lanthaler: The only good use case for this is when you convert from RDF to JSON-LD... it's arguable if you need this type of optimization. Do we need this feature, not that trivial to implement this feature?

Niklas Lindström: I kind of agree with Markus - I think that when you're automatically serializing RDF and you use prefixes for one... coercing the values for one feels half-baked to me.

Niklas Lindström: I'm a bit wary of it... in RDF, you can have all kinds of values for a certain property - you could have one value which is a language-tagged value, something else that is an xsd:string, something else that is a dateTime.

Niklas Lindström: I prefer to defer this, but would like to hear Gregg's use cases on this.

Gregg Kellogg: There are a number of cases where this may be useful - it avoids a great deal of work where you're describing things in a context. Cases for doing coercion of CURIEs are focused on converting RDF to JSON-LD - my processor creates conversion rules when they lead to a net reduction in size.

Gregg Kellogg: For example, if all dc:created are dates, then I can compress the document.

Markus Lanthaler: The context is about defining terms and prefixes.

Gregg Kellogg: I think that it's natural that people will try this - author's will do this, no good reason not to support the use case.

Gregg Kellogg: +1

Niklas Lindström: +0.1

Markus Lanthaler: -0.5

David I. Lehn: +0.5

Manu Sporny: Let's kick this back to the mailing list... Gregg, could you do a concrete proposal on this?

Niklas Lindström: I remember seeing an experiment in JSON with using prefixes, not from this community, but they were using something like CURIEs.

Niklas Lindström: So, it might be useful...

Markus Lanthaler: Fairly trivial change - rename @literal to @value... @literal is coming from an RDF background and most developers are more familiar with the term 'value' than they are with 'literal' - because a 'literal' could also be numbers.

Markus Lanthaler: @value would be better for developers - it would make it easier to understand for developers.

Gregg Kellogg: I think that literals are a common term in most programming environments... they mean something different from value - values have both simple and complex data structures... literals imply something that is not a structured element itself. integers, strings, dates - scalar might be a better term?

Niklas Lindström: The thing is that you have the value and the datatype... literal is the result of that thing.

Markus Lanthaler: Yes, literal is the combination of the datatype and the thing that we need to name... value could work.

Markus Lanthaler: Lexical representation... lexical, string, may work.

Markus Lanthaler: @value is just a token anyway...

Manu Sporny: Dave Longley is in favor of @value, so am I. It resonates more with Web developers than @literal.

Gregg Kellogg: I think RDF people might like @value more... @value might work on a number of different communities.

Manu Sporny: +1

Niklas Lindström: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +1

Manu Sporny: JSON-LD frames are not JSON-LD documents... we may want to just make them regular JSON objects.

Niklas Lindström: Has anybody thought about using the @frame keyword in a JSON-LD document?

Niklas Lindström: I may want to publish frames... they would constitute documentation for me... in those scenarios, I think that @frame would be helpful in those scenarios.

Niklas Lindström: If we're worried that people look at frames and confuse them with instance documents, we may want to add @frame.

Gregg Kellogg: I think we went through the same discussion with @context... so we decided that @context documents start with a @context key.

Gregg Kellogg: if we are going to have a data structure that has a frame, we're inevitably going to need to get that data from an IRI.

Gregg Kellogg: I don't have a way to express a frame inline, very effectively. The fact that the document is part of JSON-LD does argue that they should have something that has a JSON-LD MIMEType...

Gregg Kellogg: This is very symmetric with the way we deal with @context.

Markus Lanthaler: I don't think that frames are the same as @context... they are quite different in my opinion. You include the @context directly in a JSON-LD document, you'd never do that with a frame. The Frame is a distinct concept, separate from the document.

Markus Lanthaler: The cleanest solution would be to create a new MIMEType for JSON-LD frames.

Markus Lanthaler: Frames are kind of a query language for JSON-LD

Niklas Lindström: I'm a bit wary about MIMEType proliferation... people screw it up in usage... people are more prone to look at a document and think it looks like JSON-LD, than look at the MIMEType.

Niklas Lindström: We may want to specify @frame to make it explicit.. @frame should not be in the JSON-LD spec... it should be in the API spec.

Manu Sporny: There are two issues here - follow-your-nose and helping newbies recognize the difference between a JSON-LD document and a JSON-LD frame. The first problem is addressed by creating a MIMEType for frames. We don't know if adding @frame will address the second problem. In the worse case, we add frame and newbies still think it's a JSON-LD document and not a JSON-LD frame. We may not even want a new MIMEType because nobody looks at those, like Niklas said. JSON-LD frames don't look like JSON-LD documents, really.

Markus Lanthaler: Yes, but not having a MIMEType prevents people from doing things like having different icons, using different editor's for frames, etc.

Niklas Lindström: I still think that JSON-LD frames look very much like JSON-LD documents.

Gregg Kellogg: I think that just using a plain JSON document fails the follow-your-nose test... it needs to be a JSON-LD frame MIMETYPE or a subtype of JSON-LD document

Gregg Kellogg: There is some danger of making it too much like a JSON-LD document, but the contents are explained in the spec. You can clearly find out the meaning of that by looking at the specification.

Niklas Lindström: Look at the library example - the frame looks exactly like a JSON-LD document: http://json-ld.org/playground/playground-examples.js

Markus Lanthaler: We could put the @frame beside the @context? (a) { "@frame": { "@context": "....", "query": "..." } vs. (b) { "@context": "....", "@frame": "query..." }

Manu Sporny: Let's straw-poll to see if we want to support a MIMEType for JSON-LD frames...

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +0

Niklas Lindström: .. like "application/jsonldframe+json"

David I. Lehn: I can see people just wanting to use regular json mimetype for all these docs

Niklas Lindström: David Lehn, I believe so too

Gregg Kellogg: application/frame[+-]ld+json

Gregg Kellogg: The syntax document is almost done, we should figure out what our plan is for the next couple of months... send something to the mailing list, Manu.