Manu Sporny: Any changes or updates to the Agenda?

Gregg Kellogg: Might be worth talking about Mark Nottingham's post.

Markus Lanthaler: http://www.mnot.net/blog/2011/11/25/linking_in_json

Manu Sporny: Mark is looking for a good linked data format - his analysis of JSON-LD is a bit off.

Gregg Kellogg: yeah, he's a bit off - everything he wants to do in _meta can be done with JSON-LD context. We definitely don't need another way of expressing exactly what JSON-LD already does. He did also get wrapped up in the concept that JSON-LD is about RDF.

Manu Sporny: maybe we need to do a blog post to explain why what he's proposing is basically JSON-LD?

Gregg Kellogg: Bring TimBL into the discussion?

Niklas Lindström: I get the sense that we're going to see something akin to Microdata all over again - if people dismiss JSON-LD outright without really looking at it.

Niklas Lindström: I've seen your reply as well - Mark hasn't responded to it, right?

Manu Sporny: Yeah, no response yet.

Gregg Kellogg: I think that we may want to bring TimBL into the discussion - because this seems like another Microdata/RDFa thing... and nobody wants that.

Niklas Lindström: +1 re. timbl

Manu Sporny: Ok, I'll send an e-mail to TimBL about it... to make sure that he knows about the overlap.

Gregg Kellogg: Maybe the best thing would be to work through all of the issues and to get this into a WG at W3C.

Manu Sporny: Yes, I agree.

Manu Sporny: Does one hour earlier work for everyone?

Gregg Kellogg: What about Tom Steiner? Can he make it?

Manu Sporny: Let's change the time to 1 hour earlier. It seemed to work for the meeting today. Let's ask on the mailing list to see if it's okay for everyone?

Markus Lanthaler: Do we want to do this every week or every other week.

Gregg Kellogg: I think we should go to every week... until we eat through all of the issues.

Manu Sporny: Yes, perhaps that would be best.

Markus Lanthaler: It's difficult to meet - a call every week would be okay. Generally, I'd like to do more on the mailing list.

Manu Sporny: I have a hard time doing more on the mailing list.

Niklas Lindström: I think the telco's are very complimentary - we need these discussions.

Gregg Kellogg: We need these telcos to decide things - important to get stability in the spec.

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +0

Gregg Kellogg: Here are the various proposals: https://github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565

Markus Lanthaler: http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0053.html

Manu Sporny: I'd prefer #3 - https://github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565

Niklas Lindström: I'd be fine with #3 as well... if we use @datatype instead of @coerce... we may want to consider something like this:

Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@datatype": "@iri"} or

Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@iri": true} or

Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@coerce": "@iri", "@list": true}

Gregg Kellogg: I'm sympathetic to the point that @datatype looks a little odd. The more keywords we have, the more complicated it's going to be for people... we're twisting @datatype a little bit, but we should focus on keeping things simple.

Markus Lanthaler: "foo": {"@iri": "http://uri.foo", "@iri": true} that won't work! You use the same key twice

Gregg Kellogg: There is a different issue on @datatype and @type... I could go with either #2 or #3.

Niklas Lindström: markus, right

Markus Lanthaler: There is an alternate approach -

Markus Lanthaler: 6) "foo": {"@iri": "http://uri.foo", "@datatype": [ "@list", "xsd:date" ] }

Markus Lanthaler: 6) "foo": {"@iri": "http://uri.foo", "@datatype": [ "@list", "@iri" ] }

Manu Sporny: I don't like #6 - multiple arrays and nesting is starting to make the context look really complicated. Worried that authors are going to have a hard time with it. Any strong arguments between #2 and #3?

Niklas Lindström: #6 is just like #1, right? Just with another example for @iri?

Gregg Kellogg: Being able to specify multiple datatypes allows you to pattern match across multiple datatypes... I don't think multiple types are good for JSON-LD... wary of introducing an array in this case.

Niklas Lindström: I agree, let's not use arrays.

Manu Sporny: I'm against #6 because of the cognitive load it adds to authors.

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: + 0.5

Markus Lanthaler: +1

David I. Lehn: +0

Gregg Kellogg: There are some related issue that would be good to get out of the way... how do we specify that a particular CURIE should have a certain datatype?

Gregg Kellogg: "dc:date": { "@datatype": "xsd:date"}

Gregg Kellogg: When coming from RDF, this is important in order to generate something readable in JSON-LD.

Niklas Lindström: If you want some of the URIs to be coerced, you have to use @iri as a key in the context... if you use URIs, you impose much more on the consumer of the data anyhow... using coercion to alleviate any of the pain doesn't warrant this, really.

Niklas Lindström: You should be able to handle explicit literals in the data as well.

Gregg Kellogg: This is really an issue when serializing - we don't want to sacrifice the compactness in being able to use the datatypes in @context... if we don't have a way to do this, we'd have to create arbitrary prefixes that are not used in order to get the datatype specification.

Manu Sporny: I'm not following.

Gregg Kellogg: If we take an RDFa document and express it in JSON-LD... we have no way to define terms in RDFa - the only way to accomplish that is to manufacture terms... or make a literal with the datatypes expressed.

Gregg Kellogg: If we look at JSON-LD vs. Microdata JSON - one advantage when expressing schema-like things, we do a better job at expressing datatype ranges.

Gregg Kellogg: but that requires manufacturing terms for every schema property - we don't want to impose that burden on a JSON-LD author.

Niklas Lindström: I can see a certain merit in being able to do this - if we have defined a default vocab, I'd expect that we'd want to write something akin to this:

Niklas Lindström: "date": {"@datatype": "xsd:date"}

Niklas Lindström: "dc:date": { "@datatype": "xsd:date"}

Niklas Lindström: "dc:date": { "@datatype": "xsd:date", "@iri": ...}

Niklas Lindström: In the case of using a URI, we could add a rule stating that if the term in the context is a URI, you're not allowed to use an IRI to define what the term is defined to.

Gregg Kellogg: if it's not an NCName

Niklas Lindström: This would prevent people from re-defining URIs.

Markus Lanthaler: The disadvantage of supporting that is that - it's a term with a colon in it.

Manu Sporny: I'm concerned that this will hurt more than it helps... it's going to look very complicated to authors.

Gregg Kellogg: JSON-LD "lite" is everything that's in basic concepts... so, we can add a few advanced concepts.

Gregg Kellogg: if the mandate is for JSON-LD to deal with RDF serialization, then it becomes an important feature.

Markus Lanthaler: "foaf:homepage": { "@datatype": "@iri" }

Markus Lanthaler: "foaf:homepage": { "@datatype": "@iri" }

Manu Sporny: The reason to have this is to ensure that serializers could compact the data more easily... but at the cost of added complexity for authors attempting to understand how a context works.

Markus Lanthaler: I don't like that I'd have to create a separate term for homepage just to say it's an IRI.

Niklas Lindström: One reason we may want to support URIs in the key position in @context is to support namespaces, but that's pretty awful in JSON.

Manu Sporny: I think that this use case may be better served by JSON-LD compaction and framing.

Gregg Kellogg: I think automatically creating a context that allows terse expression is difficult without this feature... we could do this before with @coerce, but we can't now that we've combined everything together.

Niklas Lindström: .. I can go for supporting "dc:date": { "@datatype": "xsd:date"} where the @iri key is disallowed, albeit it is rather advanced

Manu Sporny: What about expanding context out... full IRI in the key position?

Gregg Kellogg: "http://purl.org/dc/terms/date": {"@datatype": "xsd:date"}

Markus Lanthaler: I don't really like that approach.

Manu Sporny: We do this for Web Payments - we compact and reframe data coming in via RDFa - so, we haven't had the need for this feature.

Gregg Kellogg: When serializing from RDF to JSON-LD - you want to be able to coerce without having someone pre-create terms. A CURIE makes it unambiguous and still makes it a fairly terse representation.

Niklas Lindström: I can see that supporting it - making it an advanced concept.

Manu Sporny: Gregg, could you create an ISSUE for this and re-raise it on the mailing list? We need some more time to think about it.

Manu Sporny: I'm pretty sure that we already resolved this, right? We decided that we would not import the data?

Niklas Lindström: I'm for not importing the data.

Gregg Kellogg: We should make it clear that the Compact API call can take both a JSON object as the context to use to compact, as well as an external IRI.