Manu Sporny: Any updates or changes to Agenda? [scribe assist by Manu Sporny]

Markus Lanthaler: Let's start with the easy ones - let's start with 96 and 97 [scribe assist by Manu Sporny]

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/96

Manu Sporny: I believe you guys resolved this already on the issue tracker

Gregg Kellogg: previously framing always returned an array where each object contained an context embedded which didn't make sense for me and Markus

Gregg Kellogg: +1

Manu Sporny: +1

Markus Lanthaler: +1

Dave Longley: +1 (via issue tracker)

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/97

Gregg Kellogg: this had to do with default values and null values in framing as nulls would have been removed

Gregg Kellogg: we use the @preserve and @null keyword now with a postprocessing step.

Manu Sporny: This is something the implementers figured out between themselves and we're happy with the solution, so let's just resolve this as done since nobody seems to disagree with the current direction.

Gregg Kellogg: I already closed the issue

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/80

Gregg Kellogg: Markus outlined that updating @type e.g. with @container by relying on the initial context is problematic

Gregg Kellogg: and we never considered to use the init. context for something else

Manu Sporny: that's a mistake we made in RDFa - we could have gone around a lot of backwards-incompatability issues by doing so

Manu Sporny: we could say that in JSON-LD the initial context is blank but this could be used to change functionality in future versions of JSON-LD

Gregg Kellogg: I can't see how this helps as an existing processor wouldn't understand that new information

Manu Sporny: it's not a full solution for that but it's better than not having it

Gregg Kellogg: we could put prefix definitions in there

Manu Sporny: what should we put in there?

Gregg Kellogg: same as in RDFa?

Manu Sporny: JSON-LD is slightly different

Manu Sporny: Discussion about whether or not xsd and rdf are useful to pre-define. Markus' position is that it is only important to RDF folks and JSON folks probably won't care about those types of datatypes.

Manu Sporny: Gregg's position is that xsd is used heavily in the spec and has a place in the initial context.

Gregg Kellogg: There is an advantage to saying that there is a default context - processors MUST load it, even if it is empty. [scribe assist by Manu Sporny]

Gregg Kellogg: There is a URL that we define in the spec that is the location of the default context - as part of expansion, all processors must load that context before doing any other processing or when resetting back to the default context. [scribe assist by Manu Sporny]

Gregg Kellogg: no, it would work but fall back on a build in initial context - meaning the processor has to be updated regularly

Gregg Kellogg: We saw this as a very useful feature in RDFa - it would behoove us to learn from the past and put this future-proofing mechanism in there. [scribe assist by Manu Sporny]

Manu Sporny: We seem to agree that if there is an initial context, it should be external to the spec. Markus is still skeptical that we need such a feature. Both Gregg and I feel that it is a good future-proofing mechanism - one that we definitely needed in the RDFa world and one that we think we might also need here.

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1 with emphasis on IF

David I. Lehn: +0

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/107

Manu Sporny: IANA and W3C and WWW-TAG groups require us to define what fragment identifiers mean for MIME Types. Keep in mind that this means what fragment identifiers mean in documents, not necessarily what they mean when IRIs with fragment identifiers are used in documents.

Manu Sporny: Markus is proposing: In JSON-LD a fragment identifier MAY identify a node in the linked data graph expressed in the document. This idiom, which is also used in RDF [RDF-CONCEPTS], gives a simple way to "mint" new, document-local IRIs to label nodes and therefore contributes considerably to the expressive power of JSON-LD.

Gregg Kellogg: what I like on Markus' proposal is that it is about an abstract concept and not a structural element which could be encoded twice in a document

Manu Sporny: I would like to be able that a browser would be able to jump to something

Gregg Kellogg: for that we could say it should jump to the first instance.. I don't know if that's something we have to specify

Gregg Kellogg: I prefer Markus' proposal

Manu Sporny: I'm fine with it

Manu Sporny: we don't need to put it in the spec

Gregg Kellogg: in terms of locating onself in a document?

Manu Sporny: yes

David I. Lehn: in the example are these full IRIs that are encoded (foo and bar)?

Manu Sporny: it could as well be just a fragment identifier which would be expanded to a full IRI by taking the document IRI

Gregg Kellogg: the question is what a fragment identifier means when it references a JSON-LD document

Manu Sporny: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

David I. Lehn: +1

Manu Sporny: NOTE: The group has discussed what graphical clients should do when given a JSON-LD fragment identifier and have come to the following conclusion: If an implementer is developing a client to view JSON-LD markup and wants to implement a feature for navigating to a fragment identifier in a JSON-LD document, the client software should navigate to the first definition of the fragment identifier in the JSON-LD document.

Gregg Kellogg: +1

Manu Sporny: +1

Markus Lanthaler: +1

Manu Sporny: The group doesn't believe that we need to put this into the spec.

Markus Lanthaler: could we talk about ISSUE-98 now?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/98

Markus Lanthaler: This started when Gregg started to discuss what should happen to native types... [scribe assist by Manu Sporny]

Markus Lanthaler: We had a number of discussions around this, but I think that Dave Longley and I said that datatype coercion should apply to native types - during expansion, those native types should be converted to strings. That should fall back on the JSON processors .toString() capabilities, probably. [scribe assist by Manu Sporny]

Markus Lanthaler: In RDF round-tripping, native types get automatically type coerced to xsd:integer - they are converted back automatically when converting from RDF to JSON-LD. Longley didn't agree with that. [scribe assist by Manu Sporny]

Markus Lanthaler: In compaction, strings are never converted to native types, all that happens there is the value is replaced with whatever value was in "@value" if the type matches. [scribe assist by Manu Sporny]

Markus Lanthaler: Conversion between native types and strings happen automatically - so a "14"^^xsd:integer would be converted to 14 in JSON-LD. [scribe assist by Manu Sporny]

Markus Lanthaler: We may want to have a flag to turn automatic conversion on/off since Longley doesn't agree that we should do the auto-conversion. [scribe assist by Manu Sporny]

Gregg Kellogg: We have a consistency issue - any processing of JSON-LD requires you to expand. Any use of native types will be replaced with strings after doing expansion, compaction, framing or RDF conversion. [scribe assist by Manu Sporny]

Gregg Kellogg: We have lost the ability to retain the native types. [scribe assist by Manu Sporny]

Markus Lanthaler: Native types are retained unless you have coercion. If you have a numeric type and you have a numeric conversion, you don't need to transform the type. [scribe assist by Manu Sporny]

Gregg Kellogg: native types are not transformed at all, they remain in their form through expansion/compaction if their meaning is ambiguous. [scribe assist by Manu Sporny]

Gregg Kellogg: Type coercion only has effect for strings. It doesn't have an effect for something in native value form, it only has effect for something that is a string. [scribe assist by Manu Sporny]

Markus Lanthaler: If you specify type coercion, it should always apply. [scribe assist by Manu Sporny]

Gregg Kellogg: Then, as an author that wants to use native types, I can do so as long as I don't coerce them to an xsd:integer type. If I have 5, and I say xsd:integer, I can't express it with a number. [scribe assist by Manu Sporny]

Gregg Kellogg: things expressed as boolean integer or double always compact down to their native representations when there is no loss involved. [scribe assist by Manu Sporny]

Gregg Kellogg: We could depend on the 'strict' flag to tell us when an inconsistency is seen. [scribe assist by Manu Sporny]

Markus Lanthaler: If you have 5, and you coerce to xsd:double - how would you preserve that in expansion? [scribe assist by Manu Sporny]

Manu Sporny: I'm concerned that we're discussing a few different issues at the same time. [scribe assist by Manu Sporny]

Manu Sporny: we could move all that automatic conversion to fromRDF/toRDF

Gregg Kellogg: it's similar to Turtle which has native forms for integers, booleans etc.

Gregg Kellogg: we could have a flag there to keep strings or convert to native types as Markus suggested

Gregg Kellogg: the xsd types are there to describe how data is stored in computers.. in JSON we do the same even though JSON is crippled as it just has "number"

Manu Sporny: Discussion about what we're discussing - we're talking about how booleans, doubles and integers are round-tripped between compaction/expansion and to/from RDF.

Gregg Kellogg: I'm really concerned that we could have a case where an author specifies true in JSON-native form, expands, then compacts and gets back the string "true". [scribe assist by Manu Sporny]

Dave Longley: During compaction/expansion, if something is a native form, can we just leave it that way? Do we all agree on that? [scribe assist by Manu Sporny]

Gregg Kellogg: Native types stay native types... that's good. [scribe assist by Manu Sporny]

Dave Longley: If there is no type coercion rule - we keep the native type. [scribe assist by Manu Sporny]

Markus Lanthaler: Do we want to use xsd:double or xsd:integer - do they expect it to convert to a JSON type? [scribe assist by Manu Sporny]

Dave Longley: It's the closest approximation we have. [scribe assist by Manu Sporny]

Markus Lanthaler: xsd:integer and xsd:double is about interoperability. [scribe assist by Manu Sporny]

Dave Longley: If you don't put any type coercion information into your context, then anything that is a string will stay a string unless you do conversion toxsd:integer in the @context. [scribe assist by Manu Sporny]

Dave Longley: We get into trouble if we force incoming triples that have xsd:integer to be converted to native type, that's a mistake. We could lose precision. It could make people not want to use it as a data transport mechanism. etc. [scribe assist by Manu Sporny]

Gregg Kellogg: Let's separate this from a to/from RDF issue, let's just talk about compaction at this point. [scribe assist by Manu Sporny]

Gregg Kellogg: If we just use compaction/expansion - if we start with something that is native form, I don't end up with something that is native form. If we don't want to get into automatic conversion, if something is in a native type - it stays in that native type. [scribe assist by Manu Sporny]

Markus Lanthaler: What information have you lost? [scribe assist by Manu Sporny]

Dave Longley: You don't know if the number is a double or not - you no longer know if you're working with an integer or a double. [scribe assist by Manu Sporny]

Markus Lanthaler: This is an issue - 5 (xsd:double) -> expansion -> 5 (no way to know that it is supposed to be an xsd:double)

Markus Lanthaler: We want to end up with this: "@value": 5, "@type": "xsd:double"

Dave Longley: The issue we have is JSON-LD: 4 (xsd:double) -> expanded 4 -> [[[long discussion about example]] [scribe assist by Manu Sporny]

Manu Sporny: Gregg is proposing that we can do: "@value": 5, "@type": "xsd:double" in expanded form.

Gregg Kellogg: My worry is JSON-LD true -> expansion "true" -> compaction "true" - data doesn't round trip correctly in JSON-LD compaction/expansion. [scribe assist by Manu Sporny]

Manu Sporny: +1

Gregg Kellogg: +1

Dave Longley: +1

David I. Lehn: +0

Markus Lanthaler: +1

Manu Sporny: Discussion about "principles of expected behavior" - there is such a thing as a native type, if they want to preserve a native type they must be able to do so.

Markus Lanthaler: +1

Manu Sporny: +1

Gregg Kellogg: +1

Dave Longley: +1

David I. Lehn: +1

Gregg Kellogg: The native value true should expand to {"@value": true, "@type": "whatever_value_they specified} [scribe assist by Manu Sporny]

Dave Longley: When compacting, @value stays the same if the datatype matches. Or it is kept in expanded form if the datatype does not match. [scribe assist by Manu Sporny]

Markus Lanthaler: +1

Dave Longley: +1

Manu Sporny: +1

Gregg Kellogg: {"@value": true, "@type": "xsd:integer"}

Gregg Kellogg: +1

David I. Lehn: +0

Manu Sporny: In strict mode, do we raise an exception for the last thing Markus just said? [scribe assist by Manu Sporny]

Gregg Kellogg: I think so, yes. [scribe assist by Manu Sporny]

Gregg Kellogg: +1

Markus Lanthaler: +1

Manu Sporny: +1

David I. Lehn: +0

Manu Sporny: So, for example: This is your data: "foo": {"@value": true, "@type": "xsd:boolean"}, this is in the @context "foo": {"@id": "...", "@type": "xsd:boolean"}, then this is the result: "foo": true

Gregg Kellogg: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +0

Manu Sporny: +1

Dave Longley: one quick thought: I was thinking about how we have a flag in fromRDF now to decide whether or not rdf:type should map to @type ... maybe we just want to do the same thing for all of the xsd stuff. In other words, in compaction/expansion, don't deal with the meaning of xsd at all; just always leave things in their native form (but include @type information when expanding like we agreed, just consider it opaque). Only when

Dave Longley: converting to/from RDF, would special conversion rules apply (to convert natives to another form). We could use mappings instead of flags with defaults to xsd. We could introduce@double/@integer/ @boolean just for that specific purpose (only used as mapping options in to/from RDF), eg: @integer => xsd:integer and vice versa. afk.

Dave Longley: pretty much what we were discussing. [scribe assist by Gregg Kellogg]

Gregg Kellogg: having a flag whose default value is true is a bit awkward

Gregg Kellogg: useNativeTypes set to 'true' is a bit awkward - if we have a flag which is used to get to the unusual case of just using expanded form, it would be more intuitive - what's the appropriate name for the flag to trigger that. [scribe assist by Manu Sporny]

Manu Sporny: I have notified the RDF WG that we think the JSON-LD Syntax is stable and that we introduced the concept of named graphs.

Gregg Kellogg: JSON-LD is stable: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0274.html

Gregg Kellogg: JSON-LD introduced named graphs: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0275.html

Gregg Kellogg: We should send a response to Sandro about the usage of Layer instead of graph - probably don't want to use layer. [scribe assist by Manu Sporny]

Manu Sporny: I'll do that. [scribe assist by Manu Sporny]