Markus Lanthaler: This issue came up in IRC, discussion about framing - there are different ways to express a value in JSON-LD - plain literals, or a JSON number, etc. Directly as a property value or via @value - in expanded form.
Gregg Kellogg: With regard to @graph, it was an issue with subject references - should it be in expanded form {"@id": "http://graph.id/foo/bar"} or just "http://graph.id/foo/bar" - the @value issue is only one of the issues.
Gregg Kellogg: Does expanded form really mean "expanded", or do we do some amount of compaction in expanded form?
Markus Lanthaler: I always saw expanded form in as just IRI expansion.
Markus Lanthaler: Not just IRI expansion but primarily IRI expansion
Manu Sporny: the intent in the beginning for expanded form was to have a regular data structure that you could easily code against - the more regular, the easier it is.
Markus Lanthaler: My issue with this is that we may not want to go all the way on this - we may want to do a slight amount of compaction.
Manu Sporny: we have two issues here 1) whether or not to expand @graph to have a value of a JSON object with "@id" in it in expanded form, and 2) whether or not all values get expanded to a JSON object containing "@value" in expanded form.
Manu Sporny: one concern that you have, Markus, is the amount of overhead expanded form has.
Markus Lanthaler: Most of the time you just deal with the native datatypes and that is enough - that is, expanded form is not very useful for JSON developers.
Niklas Lindström: Would regular JSON developers like to deal with expanded form at all?
Manu Sporny: Would they want to use compact form more often?
Niklas Lindström: Yes, the shape of RDF/JSON is always predictable - but it's illegible for anyone expecting plain old JSON. The expanded form of JSON-LD is very similar to RDF/JSON in expanded form.
Niklas Lindström: I don't think we should expand anything that is predictable in a less expanded form... which kind of developer are we catering for...
Markus Lanthaler: That's a bit difficult, everyone has their own idea on how this is going to be used.
Niklas Lindström: Based on the shape of the expanded form, we should expect that people want to get it into their JS and just do something with it... this is an information exchange format for extremely detailed info.
Markus Lanthaler: Since all IRIs are expanded, it makes it very useful.
Niklas Lindström: Yes, but only if you want to express the RDF description - it's middleware.
Gregg Kellogg: it's not the type of JSON that a developer would typically expect... that's what framing and compaction are for. Expansion is to get something in a more normal form so it can be further processed. Every time I have a property, the value is expressed as an array of objects - that simplifies things.
Niklas Lindström: Yes, exactly, you should always be able to know what to look at next - normal form is good.
Manu explains the logic behind the current direction.
Markus Lanthaler: Example of how this makes things simpler?
Manu explains converting to n-triples and branching.
Gregg Kellogg: This not only applies to N-Triples - you have to check the value of each property - is it a number, a boolean, a string, or a JSON object? There is going to be branching, but it does simplify the logic in the program.
Niklas Lindström: If we don't do this, but allow plain values directly - you'd have to first check if it is an object - it's a more complex algorithm if we mix the types.
Niklas Lindström: This is very consistent with how similar formats work - SPARQL and RDF/JSON - there is a regularity in their shapes.
Manu Sporny: I think there is broad agreement between Gregg, Niklas, Dave Longley and myself on this being the proper direction.
Markus Lanthaler: I won't block if you guys agree - still have a hard time seeing the value in this.
Manu Sporny: We can always rewind this decision later if it turns out to be a bad idea.
Markus Lanthaler: So, @id, @type, and possibly @graph are the only things that are not expanded to @value form?
Gregg Kellogg: Still need to discuss @graph, but yes.
Markus Lanthaler: hmm
Manu Sporny: There hasn't been much support for literals as identifiers over the past 10 years... mint a new IRI scheme if you need to -myid:FooBar
PROPOSAL: In general, for expansion, ensure that all property values are expressed in expanded value form (e.g. {"@value"; 5}, {"@value"; "foo"}, {"@id"; "http;//example.com/"}) with the exception of @id and @type.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +0
RESOLUTION: In general, for expansion, ensure that all property values are expressed in expanded value form (e.g. {"@value": 5}, {"@value": "foo"}, {"@id": "http://example.com/"}) with the exception of @id and @type.
Manu Sporny: Next question we need to address is whether or not @graph is expanded value form in expansion.
Markus Lanthaler: Is there any reason to have graph expanded?
Manu Sporny: It's more modular code to process it if we express it in expanded value form - and we have a clear way of supporting literal names for graphs.
Gregg Kellogg: Postel's rule - strict in what you generate, lenient in what a processor does.
Manu Sporny: Authors/processors must not generate this in expanded form: "@graph": "http://foo.bar/" - but a processor must read that as an IRI if it sees it.
Gregg Kellogg: In the case of @graph, my processor acts as if there is a coercion to @id (it can be a relative IRI), or you could use a fragment ID in that case.
Manu Sporny: Is this the right way to go, Markus?
Markus Lanthaler: Based on the previous train of logic, yes.
PROPOSAL: In expanded form, @graph must be expressed in expanded value form (e.g. "@graph"; [{"@id"; "http;//example.com/foo#graph}])
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0.5
RESOLUTION: In expanded form, @graph must be expressed in expanded value form (e.g. "@graph": [{"@id": "http://example.com/foo#graph}])
David I. Lehn: +0
Markus Lanthaler: When compacting what happens?
Gregg Kellogg: Act as if there is a coercion to @id
Gregg Kellogg: if we were to accept values, which we don't currently, they would be kept in expanded form - for numbers, booleans, (if that would ever make sense) - keep it in expanded form.
Niklas Lindström: It's worth noticing, this doesn't result in any RDF...
Gregg Kellogg: We have this so you could name a linked graph - a property that references a graph with an IRI - this thing names the reference resource using the @id of the object containing graph.
Markus Lanthaler: Wouldn't it be easier to understand if we keep the expanded form in this case?
Niklas Lindström: I think so - in compact form, we should keep this shape.
Gregg Kellogg: It's not ambiguous, processing rules tell you exactly how to treat that...
Markus Lanthaler: If you know the spec, then yes - but for someone that doesn't know what's going on - they're not going to understand that that's a graph that is elsewhere?
Niklas Lindström: If I just glanced at it, I'd expect that to be the graph identifier.
Gregg Kellogg: Yeah, I see.
Gregg Kellogg: If we want to allow a linked representation of graphs - if I have one document that names a graph that is identified as being in another document - having that as an IRI is a natural way to express that, right?
Gregg Kellogg: We could make that illegal - this seems like a HTTPRange-14 issue - you can't interpret the document w/o the reference to it to interpret the document.
Markus Lanthaler: I'm saying that we shouldn't compact that by default.
Gregg Kellogg: Maybe that's a named graph with no content - how would I express that I'm not identifying an empty graph - I'm referencing another document.
Niklas Lindström: This seems like a conflation between syntax and semantics. I can't really see the use case for this.
Gregg Kellogg: The problem with named graphs is that there is only one name - what is the context in which you're naming - in WikiData, they want to name each statement with it's own provenance - it requires the SNIK to be encapsulated inside another object that contains provenance information.
Gregg Kellogg: Having stuff at the granularity where you're naming makes it more difficult - you want a different dimension on name in that case - being able to remotely reference a graph allows you to have the same triples associated within the same context - if you only have one dimension of naming, you can't do that.
Niklas Lindström: I don't see why this specific construct addresses your use case, Gregg. Seems like you need reification to solve that.
Gregg Kellogg: reification seems like it's being obsoleted.
Gregg Kellogg: This comes back to the notion of JSON-LD being Linked Data and the ability to link to graphs being named.
Gregg Kellogg: It's not simply an object or an array of objects, but also potentially subject references that could be strings that are IRIs.
Gregg Kellogg: Fundamental question is do we want to enable linking to external documents and naming them using the named graph syntax, or not? If not, is there some better way to express the intention that the subject reference is intended to have the document dereferenced.
Niklas Lindström: (the above is a graph of graphs, each triple in its own named graph)
Markus Lanthaler: This is not really an issue - more of trying to get an understanding - what's the value space of the different keywords? Does @type support just strings, or arrays of objects?
Markus Lanthaler: I want us to all agree on the value space of all of our keywords.
Gregg Kellogg: The case for @type and @id is if it can accept {"@id": "http://example.com"} ?
Niklas Lindström: Given postels law coming up before - we might want to define the value space of the keywords - but accept something more. We allow stranger values to appear, but we turn them back into something not awful.
Manu Sporny: The concern is making implementations more complex.
Niklas Lindström: Yes, XHTML vs. HTML5.
Manu Sporny: The goal would be to try and standardize the way weird things are interpreted in JSON-LD.
Gregg Kellogg: There is syntactic normality and then semantic normality - this has more to do with semantic normality.
Gregg Kellogg: Like, do we allow arrays for @id? We say it's not valid, but then we might say that if a JSON-LD processor sees it, pick the first item in the array.
Niklas Lindström: Yes, we could do something like that.
Gregg Kellogg: We could have a part in the API spec that states how a processor reacts when it meets multiple values when it expects a single value. If it expects a string and is presented with an object, then it deals with it in another way.
Discussion about value spaces described in ISSUE-114 by Markus.
General agreement that the list generated by Markus is good, modulo that @graph shouldn't allow "string" and @list and @set should be expanded upon to make it more clear about the types of permutations allowed.
Markus Lanthaler: Should we throw an exception when value space is messed up?
Gregg Kellogg: No, we have a "recovery value space" - so, if somebody uses {"@id": "http://schema.org/Person"} w/ @type, we can still interpret it - exception is thrown in strict mode, otherwise modified in lax mode.
Markus Lanthaler: If you turn of @type in fromRDF - I don't know why we'd support coercion to @type later on.
Gregg Kellogg: We have to support coercion of keywords to other things - normal JSON allows a context for that.
Niklas Lindström: Are you talking about coercion to type @type.
Markus Lanthaler: a JSON document won't have RDF type in there.
Gregg Kellogg: Is Postel's law built into JSON-LD - when parsing input, are we forgiving of the form of that input?
Gregg Kellogg: Do we turn it into a more normal form or not - that's what strict mode does - it allows you to be pedantic about your input.
Gregg Kellogg: However, in lax mode - we should do what we can to allow it... if the value-space is that of a subject definition or subject reference - it's to be interpreted as an IRI.
Niklas Lindström: If it's unambiguous, we can do something about it.
Markus Lanthaler: Yes, but implementers need to know when to throw an exception.
Markus Lanthaler: We should discuss the most forgiving mode the implementation has to support - we should discuss the least forgiving case as well and what the value space there is.
Gregg Kellogg: I think we accept things that are not in array form - that is, when the author's intention is clear then we should support the transformation.
Manu Sporny: As a general rule - we're saying: If the author's intent is clear, we should transform it into proper JSON-LD.
Niklas Lindström: Maybe we should call it 'preferred' form instead of 'strict'.
Discussion about what "form" means...
Niklas Lindström: The "preferred form" is the way you should express your form... but we read in forms that are non-preferred, but in which the author's intent is clear.
Markus Lanthaler: My concern when I wrote this issue was to define the input value space for a processor.
PROPOSAL: In general, if the author's intent is clear, we should transform the input into proper JSON-LD (keeping the processor mode, if any, in mind - in strict mode, throw exceptions, in lax mode, attempt to interpret the value).
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1 for the first part
David I. Lehn: +0
RESOLUTION: In general, if the author's intent is clear, we should transform the input into proper JSON-LD (keeping the processor mode, if any, in mind - in strict mode, throw exceptions, in lax mode, attempt to interpret the value).
Gregg Kellogg: We need a way to make the test suite set processor mode flags.
Markus Lanthaler: What about when you expect that an exception should be thrown?
Gregg Kellogg: nope, not yet - need to update the test suite.
ISSUE-81: Data round tripping issue (not enough precision)
Gregg Kellogg: I think we agreed that when expanding, the value is kept as-is last week. We don't convert when expanding/compacting or framing. That moved the issue to RDF conversion.
Gregg Kellogg: I think Dave Longley said that we should add options that express how to deal with each of the different primitive datatypes.
Markus Lanthaler: That was about which datatype is used - xsd:boolean or xsd:integer - but not about %1.15E.
Gregg Kellogg: There is a normalized form for each of the XSD types - normalized form is very close to %1.15E - trailing zeroes in the fractional part are trimmed, extra leading zeros in mantissa are trimmed as well. %1.15E always uses two characters and then all 15 digitals.
Markus Lanthaler: Couldn't we just say that we rely on the underlying toString() function to convert to decimal string?
Gregg Kellogg: if all implementations do the same thing, yes - if not we can't do that.
Gregg Kellogg: We're going to/from the abstract syntax - the representation of a decimal is the abstract representation - a string with a datatype %1.15E
Gregg Kellogg: If I go to/from TURTLE, there may be no transformation made when we turn it into the expanded form - Markus' point is that by requiring this format transformation, we're doing something different from other RDF representation - why not just use toString().
Gregg Kellogg: Our tests are testing the value-space, but not the abstract value space.
Discussion on what underlying JSON implementations use to support doubles - 32-bit, 64-bit, or 128-bit...
Markus Lanthaler: I don't have a strong opinion about 64-bit or 128-bit conversions.
Markus Lanthaler: Why don't we express the output as a 64-bit floating point representation?
Gregg Kellogg: Any processor should be able to express 1.15E consistently - if we don't do that and rely upon toString() - someone might implement tests against values and twootherwise-conforming implementations might fail.
Gregg Kellogg: from a practicality point of view - we can't just do JSON value-space conformance tests...
PROPOSAL: When converting toRDF(), any value that is a JSON number that has a fractional value MUST be treated as an xsd;double using the printf("%1.15E", number) representation.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +0
David I. Lehn: +0
RESOLUTION: When converting toRDF(), any value that is a JSON number that has a fractional value MUST be treated as an xsd:double using the printf("%1.15E", number) representation.
Topic: ISSUE-112: Define mandatory API parameters (options)
Gregg Kellogg: I think having mandatory options is a bit odd - if it's an option, it's not mandatory.
Manu Sporny: We can't necessarily do that for something like base IRI - well, I guess we could specify that the default for base IRI is "_:"?
Gregg Kellogg: Or if the base IRI is not set, the processor should try to use the base IRI of the document if it is known.
Gregg Kellogg: For the fromRDF() case, you may have flags like "@boolean" - the use of that, results in a native JSON representation.
Gregg Kellogg: There are options to control this behavior for each native type.
Markus Lanthaler: This is fine - but we have to specify this somewhere. The base has to be passed if the document is passed as an already parsed object and it has IRIs in it.
Gregg Kellogg: So you're saying, if a document is parsed that does not have a location, then the base IRI must be set to an absolute IRI.
Markus Lanthaler: We require it all the time, or we throw an exception when you find a relative IRI.
Gregg Kellogg: In TURTLE, it's common for the output to be output in relative form. I don't see another RDF processor that requires that a base IRI be provided.
Manu Sporny: Why don't we just use "_:" as the base IRI.
Markus Lanthaler: That requires us to remap all blank nodes in expansion?
Gregg Kellogg: yeah.
Gregg Kellogg: We could say that behavior is processor-dependent - I typically default it to example.com.
Gregg Kellogg: That allows you to take a format that you can see - allows you to see that it's illegal.
Markus Lanthaler: If we don't expand it to a full IRI or blank node, it's properties would get dropped.
Markus Lanthaler: Is it really bad to throw an exception in this case?
Manu Sporny: Not really, no.
Manu Sporny: I think the playground sets the base IRI
Markus Lanthaler: Why not just set it to the document IRI, and then "http://example.com/" if that doesn't exist - I don't think developers would have an issue with that?
Gregg Kellogg: In this case, I treat it as if it is an absolute IRI w/o validating it as such.
Markus Lanthaler: Can a property ever be a relative IRI?
Gregg Kellogg: In my case, it's not a property - if a property is a relative IRI, it's dropped. For subjects and objects are expanded relative to base, but in the absence of base, they're just used directly.
Markus Lanthaler: If you specify a relative IRI via @id in the @context, what happens.
PROPOSAL: The default for the base IRI for JSON-LD API methods is the current document IRI if in a browser context, or the empty string if there is no document context.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: The default for the base IRI for JSON-LD API methods is the current document IRI if in a browser context, or the empty string if there is no document context.