Gregg Kellogg: nevertheless a flag to control whether only standardized RDF is outputed would be helpful
Paul Kuykendall: absolutely
Gregg Kellogg: the problem with skolemization is that it happens by using the server's address which might be problematic in some cases
Sandro Hawke: I think it is fine to skolemize with a fixed URL e.g. w3.org
Markus Lanthaler: Since we just specify it quite generically, isn't this something that has to be done at a layer above the algorithm? [scribe assist by Manu Sporny]
Gregg Kellogg: good point. [scribe assist by Manu Sporny]
Manu Sporny: Yes. This is also true for things that have to do with normalization etc.
Gregg Kellogg: Agreed, but we should probably add a note
PROPOSAL: Add a note to the toRDF() algorithm warning developers that blank node predicates and graph labels will have to be translated before the toRDF() algorithm is run in order to ensure compatability with RDF Concepts 1.1.
Markus Lanthaler: We currently have this in the spec:
"This algorithms converts a JSON-LD document to an RDF dataset. Please note that RDF does not allow a blank node to be used as a graph name or property, while JSON-LD does. JSON-LD-RDF Converters can work around this restriction, when converting JSON-LD to RDF, by converting such blank nodes to IRIs, minting new "Skolem IRIs" as per Replacing Blank Nodes with IRIs of [RDF11-CONCEPTS]."
isn't that enough?
Dave Longley: we may wanna use "may" instead
Manu Sporny: I think what Markus just put in IRC is enough
Sandro Hawke: ok, I would be fine with that
... if you have some arguments please join the discussion in the RDF WG
Manu Sporny: I have problems seeing us making the same points over and over again
... we made our arguments quite clear I think
... no convincing technical argument against it has been raised so far
... So Sandro, I don't know what you want us to say. I feel like we are repeating ourselves
Sandro Hawke: maybe some people didn't see the points you made before so repeating them might help
Manu Sporny: I just find it slightly frustrating
Sandro Hawke: are you guys willing give up bnode predicates if you get bnode graph labels
Manu Sporny: seems like negotiation which is dangerous if there are technical arguments for features
Markus Lanthaler: The discussion here is around two positions - 1) move conversion from fromRDF to compaction/expansion, 2) keep it in to/from RDF conversion algorithm. [scribe assist by Manu Sporny]
Markus Lanthaler: We don't need to add complexity to JSON-LD processors. [scribe assist by Manu Sporny]
Markus Lanthaler: We also need to outline how this works in detail... xsd:integer vs. xsd:double, there are details we need to work out. All integers are floats in JavaScript... in certain cases, such as a xsd:double, it would become an integer. [scribe assist by Manu Sporny]
Gregg Kellogg: There is another argument, if it's done as part of compaction, it could make use of typecasting as a part of a property to get the appropriate format. [scribe assist by Manu Sporny]
Markus Lanthaler: Type coercion only applies to strings, it doesn't apply to numbers of booleans. [scribe assist by Manu Sporny]
Sandro Hawke: If it was a string, type conversion could convert it to a number - it could be converted into a JSON Number. [scribe assist by Manu Sporny]
Markus Lanthaler: Are we talking about literal to native types. [scribe assist by Manu Sporny]
Gregg Kellogg: Native types don't matter, you could easily do that in RDF transformation phase... it could be integer, double, etc. The problem is the other way arond - going from a number to a stirng. [scribe assist by Manu Sporny]
Gregg Kellogg: In order to get appropriate output form. if you had xsd:decimal, and a string "0.2323" - then transformation could generate xsd:decimal in output. [scribe assist by Manu Sporny]
Markus Lanthaler: Yes, but that would change our algorithms quite dramatically. Type coercion/language tagging is only used if it's a string. [scribe assist by Manu Sporny]
Sandro Hawke: +1 move conversion to expansion/compaction, +1 convert all numeric types to Number
Sandro Hawke: I haven't used the JSON-LD API
... but my feeling is you want that in expansion/compaction
Sandro Hawke: I had not used the JSON-LD API ever, so I don't have a lot of weight. My feeling is that you'd want this in expansion/compaction. Even if I'm not going anywhere near RDF, if I get some JSOn-LD from across the net, and my code just wants to deal w/ numbers, it might come in with xsd types on numeric things. I'd want to be able to convert those to numbers. [scribe assist by Manu Sporny]
Sandro Hawke: the other way I would expect all numbers to go to just xsd:double
Sandro Hawke: I'd also want something going the other way too, I think. I'd expect all numbers to go to double. Anything else is going to be fuzzy. It's going to be lossy, whatever you do. [scribe assist by Manu Sporny]
Sandro Hawke: Unless you have more type information. [scribe assist by Manu Sporny]
Sandro Hawke: One more argument for putting it in expansion/compaction - I want to dissuade people doing this when they convert to RDF. I think it's bad to do this before sending this to some place unknown. [scribe assist by Manu Sporny]
Dave Longley: what we want here is probably something more fine-grained
... you might want to be able to convert just certain things based on your context
Dave Longley: compaction option? convertToNativeNumbers: ['xsd:integer', 'foo:bar']
... so we might wanna do it in expansion and compaction
Sandro Hawke: How about another routine? NativizeNumbers
Stian Soiland-Reyes: you can't put all as xsd:double - 9223372036854775807 (max of xsd:long) would become 9223372036854775808 after a trip through xsd:double
... only type-coerced properties would be converted to native types then
Niklas Lindström: I don't have strong opinions here
... I think putting it in both places makes sense
... and it also makes sense to be able to control what to convert (e.g. just integers)
Sandro Hawke: Grrrrr. Can't connect via VOIP or Telco. Telco gets me a fast busy. VOIP call times out.
... if you get JSON-LD you might wanna re-compact it to get native types
Markus Lanthaler: What Dave said certainly makes sense
... but I think that could be done as a proprietary extension to JSON-LD processors
... do we really need to standardize this?
... This would probably mean that we need through another LC
Gregg Kellogg: I liked Markus proposal to go through RDF conversion to convert literals to native types
... you loose the structure of the document but the use case here is really for data coming from RDF so it shouldn't matter much in practice
Dave Longley: The downside of this is that there isn't any fine-grainded control
... you could potentially loose data
Gregg Kellogg: yeah, but we dealt with this issue for such a long time and this is what we decided to do
... there's not really new information suggesting that we need to change it
... I think following a minimalistic approach is the way to go here
Manu Sporny: the initial concern was raised by Sandro
... it was about data fidelity
... in that case just don't convert to native types
... if we change the default value so that there's no data loss that concern should be addressed
... of course there are other options with some advantages but they make the algorithms more complex and probably mean another LC
... so, if we would change the default value of useNativeTypes would that address your concerns Sandro?
Sandro Hawke: it is not my desired outcome but I could live with it. Also just adding a note making it clear to not send native types over the wire may work
Manu Sporny: this buys us time to gain experience how this will be used
... otherwise we might risk introducing other issues in the last minute
Gregg Kellogg: but that doesn't give developers a tool which don't care about RDF to convert literals to native types now
Dave Longley: I think what Manu says is that we extend it in the future
Dave Longley: s/dave/sandro
Gregg Kellogg: we should at least add a note explaining that RDF roundtripping can be used for this
... I also liked Markus proposal about adding a function wrapping that round-tripping in a simple call
Manu Sporny: So the proposal is to change the default value of useNativeTypes to false and add a note explaining the use of RDF round-tripping
PROPOSAL: The default value of the useNativeTypes flag should be set to 'false' in the JSON-LD API.
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
Clay Wells: +1
Markus Lanthaler: +1
Stian Soiland-Reyes: +1
Niklas Lindström: +1
Sandro Hawke: +1
Vikash Agrawal: +1 (take one from me)
RESOLUTION: The default value of the useNativeTypes flag should be set to 'false' in the JSON-LD API.
PROPOSAL: Add explanatory text to the JSON-LD API specification explaining the risks of the useNativeTypes flag and how to do proper conversion to/from native types using the to/from RDF method call.
Markus Lanthaler: We could add it to the data round-tripping section. [scribe assist by Manu Sporny]
Gregg Kellogg: +1
Dave Longley: +1
Manu Sporny: +1
Vikash Agrawal: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Stian Soiland-Reyes: +1
Clay Wells: +1
RESOLUTION: Add explanatory text to the JSON-LD API specification explaining the risks of the useNativeTypes flag and how to do proper conversion to/from native types using the to/from RDF method call.
Topic: The Candidate Recommendation Phase
Markus Lanthaler: When are we going to CR? [scribe assist by Manu Sporny]
Manu Sporny: We need to do some updates to the spec, maybe in 2-3 weeks. [scribe assist by Manu Sporny]
Gregg Kellogg: we also need to stabilize the test suite
Dave Longley: we didn't talk about the other XSD data types
... we currently just support xsd:double and xsd:integer
... what about the other numeric types
Markus Lanthaler: that was something that Pierre-Antoine (or Sandro, can't remember) proposed
Topic: Other concerns and news
Manu Sporny: Currenty, fromRDF creates nodes for things that are only in the object position.
Manu Sporny: We may want to discuss support for xsd:short and other integer types.
Manu Sporny: We should also discuss issue 253
Vikash Agrawal: manu-db, I just have one question as I wanted to know how Google is using JSON-LD in GMail?
Niklas Lindström: I saw people talking about JSON-LD at #elag2013 and wondered: "How in the hell did they hear about it?!" :P [scribe assist by Manu Sporny]
Manu Sporny: now I know.
Niklas Lindström: saw a number of very nice comments from the audience during your talk.. lots of "ooh, JSON-LD, gonna have to check it out" [scribe assist by Manu Sporny]
Manu Sporny: :) I think the first mention was from Herbert van de Sompel in the keynote though; and it was mentioned in some other talks as well. Which was really nice (and prompted me to talk about it). [scribe assist by Niklas Lindström]
Niklas Lindström: Did you plan to talk about it? Or did you just decide while you were there? [scribe assist by Manu Sporny]
Manu Sporny: while I was there. I wrote up the title before I'd decided on the topic. ;) [scribe assist by Niklas Lindström]
Niklas Lindström: .. needed to assess what the crowd was interested in. JSON-LD is quite great for library data, which is internally rather minutely detailed and "feels local", but has to be mashable and coordinated with the "wilder" web.
Niklas Lindström: it's a really good slide deck - concise, cuts right to the point. [scribe assist by Manu Sporny]
Manu Sporny: thanks! I aimed to make it true to the title. ;) [scribe assist by Niklas Lindström]