Sandro Hawke: manu, your saying that a larger class of JSON documents requires BNode predicates.
Manu Sporny: I was surprised that RDF being such a universal format, could not support basic JSON. I think it needs to be fixed in the RDF data model, and we're just going half way there for JSON-LD.
Sandro Hawke: I'm dubious that that class is of interest.
Manu Sporny: that's most JSON documents.
Sandro Hawke: you don't have interoperability without mapping to IRIs.
Niklas Lindström: I don't see the use case for mapping regular JSON either, as you don't know what it means.
… It's more reasonable to think that they represent string literals, than blank nodes (not supported either).
… The JSON that has no defined meaning isn't interesting. If the keys are interesting, you should set a @vocab in the context.
David Booth: It seems natural to me to map them to relative URIs, via a default vocabulary.
Markus Lanthaler: another use case is that you might be interested in some parts of the data and not map everything. You can map to BNodes first, and then continue mapping later.
… I might just be interested in mapping the authors of a blog post, and map the rest to bnodes.
Sandro Hawke: +1 to that use case, but how about just skip them....?
David Booth: But those could just as well have been mapped to relative URIs.
… If not mapped, you'd losses the tree structure that connects nodes.
Sandro Hawke: map them all to rdfs:seeAlso :-) (the null relation)
… You might just want to see all people involved in a discussion, but not the predicates that relate them.
Niklas Lindström: For the record, I'm not particularly opposed to supporting this
… If you have data and terms in the JSON which seemingly mean nothing, there's a good case for preserving the structure.
David Booth: a relative IRI would work just as well.
Dave Longley: i would support an option for generalized RDF too -- i don't mind it being false by default.
Manu Sporny: I disagree: you could make the opposite argument.
… because you don't want the identifier to be relative to the document; you don't want someone else to be able to reference it from outside the document.
David Booth: that's anti-web.
Manu Sporny: it doesn't matter in that particular case. I think that's a shaky argument to make.
Niklas Lindström: why would you imply that others can use the predicate when the developer themselves doesn't know what it means.
Manu Sporny: W3C has created other specs which are anti-web, that doesn't mean that they're not good use cases.
Manu Sporny: the other part of blank nodes is when you don't want to create an identifier that isn't well known. You need to reference on the wire, but don't want a long-lived identifier.
Dave Longley: I recommend we discuss the option for supporting generalized RDF as an option, false by default.
Manu Sporny: this would be a flag in the toRDF algorithm.
David Booth: the problem with that route is that you'd have unnecessary information loss, instead of being usable.
Manu Sporny: that's not necessarily true, you shouldn't be generating them in the first place.
David Booth: information is lost, because triples are lost.
Markus Lanthaler: you could always skolumize if you want to preserve them.
Manu Sporny: in you're case, you'd skolumize every predicate you have access to. Or, talk to the publisher to make sure the data is preserved.
David Booth: I think skolumization is more complicated than needed; I think that standards compliant parsers always produce the same triples, without information loss.
Niklas Lindström: .. How about on_illegal_bnode_ids = drop | keep | skolemize ?
Gregg Kellogg: there are other places where there is information loss - unmapped keys for instance
Niklas Lindström: I wouldn't like to introduce a dependency on skolemization at this low level.. an app can do that if it needs to [scribe assist by Markus Lanthaler]
Markus Lanthaler: True. Maybe 'skolemize_if_able'.. ;] [scribe assist by Niklas Lindström]
Gregg Kellogg: The easiest thing to do is just to use @vocab -
David Booth: by prohibiting bnode properties we gain RDF alignment and downstream use.
Dave Longley: I think authors will just not output the data; some authors just won't map it.
… The alignment with RDF can always be with the option.
David Booth: the author could just as well have used relative IRIs.
Dave Longley: I think some authors don't actually want to map their properties to global things; we can cover these use cases.
David Booth: I didn't find markus argument convincing.
David Booth: Let's take this back to the list with an example use case.
Dave Longley: a website might have an API which serves JSON; some of the properties are only intended for local use, but they're not meant to be used outside of the API. This allows for a single API that serves both purposes.
… It's based on the type of context you use to publish.
Manu Sporny: we need a proposal which we can get consensus on. I don't see anyone available.
… It doesn't seem like the group want's to get rid of this feature.
ACTION: Dave Longley to post blank node predicates example to list.
Markus Lanthaler: given that we have generalized datasets, it does align to RDF.
Topic: RDF Alignment Editorial Changes
David Booth: there are still a few editorial things in the main JSON-LD document: title of section C1 should be "to RDF model", not just "to RDF"
… The API document hasn't had updates for terminology.
… Basically, some of the terminology implies that JSON-LD is not RDF.
Manu Sporny: please point out specific references to be changed.
… This is an appendix, so issues of readability and so forth, should not be valued, and issues of completeness are most important.
… Any attempt to justify things in an appendix will not be of value to me.
Manu Sporny: there's another issue that we might not leave these as appendicies
… However, it will still remain in the back-matter of the document.
Peter Patel-Schneider: the main remaining bits have to do with numbers. I just spent a lot of disagreeable time trying to figure out what JSON numbers are.
… The rational does not seem to be supported in any of the JSON documents.
… The only things which talk about what JSON numbers really are fall on it's being IEEE, so 0 === .0
Manu Sporny: what you're seeing is why a whole new JSON group was chartered
… I think it's clear what our interpretation is.
… We might be in a case where was say how we interpret the spec-text.
… If we're going to change our mind, we need a compelling reason to do so.
Peter Patel-Schneider: as far as I can tell, you pulled this out of thin air.
… Every document is either silent, or indicates that JSON numbers are IEEE floating point numbers
… RFC4627 says JSON is derived from ECMA-script. It's then silent on what numbers are, and defers everything else to ECMA-script version 3.
Markus Lanthaler: the only reference says that it's derived from ECMA-script, but is different.
Peter Patel-Schneider: I need a standard reference.
… W3C is voting on a standard which refers to JSON; if JSON isn't built on ECMA-script, it's built on nothing.
Markus Lanthaler: it's a serialization point built on a grammar.
Peter Patel-Schneider: they weight is on JavaScript compatibility, if not otherwise specified.
Markus Lanthaler: we've tried to do the best we can do, without size restrictions.
… I most cases it works right, in others, we can't do anything about it.
Manu Sporny: JSON is widely used, so the idea that it's going to result in a catastrophe, it would have happened long ago.
… I understand you're saying that the foundation isn't solid, and that specs are ambigious...
… There's not a wide agreement that ECMA is the JSON data model.
Sandro Hawke: JSON-LD conforms to the JSON syntax, and JSON-LD has its own data model that conforms to JSON practice.
… That's why the new JSON group has been created; in the mean time, we need to make progress.
… If you look at 4627, you may disagree with how to interpret it, but we have concencus on how to intpret it: JSON numbers do not have a limited range.
… I know that's not perfect, but it's something that implementors can use.
Peter Patel-Schneider: I would be fairly happy with canning the size limitations, but we have real interoperability issues between integers and floating point.
… 0 vs. .0, are they the same number.
Markus Lanthaler: in JSON-LD they are the same.
… Numbers without fractions are interpreted as integers.
Dave Longley: we need to clarify in the text that we differentiate between numbers
Peter Patel-Schneider: if you're going there, we're into numerical analytics territory.
… The most conservative way would be to just use IEEE floating point, and not integers.
Manu Sporny: that has a number of horrible implications.
Peter Patel-Schneider: that's what ECMA-script specifies, all numbers are floats.
Peter Patel-Schneider: ECMA-script is clear that all numbers are IEEE floating point doubles.
David I. Lehn: we saw this number before, as parsers will return either integers or floating point, depending on if there's a zero fractional part.
… This require that types to provided explicitly. It hasn't really been a problem so far.
Peter Patel-Schneider: I think that Appendix A should state what's going on.
Manu Sporny: yes, we can be more clear.
… what specifically are we not being clear on?
Peter Patel-Schneider: my last several suggestions had wording to support this, which I reiterated in my last email.
… Integers map to xsd:integer, and "dotted" numbers map to xsd:decimal.
Manu Sporny: most implementations we work on don't do that, as we don't have access to the parser.
Markus Lanthaler: we can still rely on the non-zero fractional part of the number. 0.0 is the integer 0. That's explained in Appendix C
Manu Sporny: we need some correc stolid spec text; we didn't think the text you provided could be added.
Peter Patel-Schneider: that's why I tried to produce actual text.
… If you're going to say that it's incorrect you need to say why.
… There are also lots of implementations that turn everything into double.
Manu Sporny: we'll go over it again on the mailing list.
Markus Lanthaler: All remaining issues are in the data model section?
Peter Patel-Schneider: the last time I looked I was not unhappy with what I saw.
Markus Lanthaler: Appendix C has a note that discusses number transformation.
… non-decimal is not clear enough.
Peter Patel-Schneider: I was asking about 0 and 0.0.
Markus Lanthaler: the text has been in for the last couple of months.
Dave Longley: it's a moving target, and that makes it difficult.
Sandro Hawke: that's why we have VERSION DATES.
Peter Patel-Schneider: what is needed is some notion of clarity about what's going on so that people can understand what the different JSON number encodings actually mean.
… It's up to you how the JSON people will deal with this.
Dave Longley: I think there's general confusion about JSON number throughout different communities. Implementations sometimes do different things.
… We're trying to work with the different parsers which already exist out there.
Markus Lanthaler: as a way forward, would it help to move that note to the data model, instead of in the relationship to RDF?
Peter Patel-Schneider: my view is that there should be some mirroring of that in Appendix A
… Im happy to compress Appendix A, but it should be stated there.
… As long as Appendix A alludes to the right things ...
Markus Lanthaler: we'll add a note in Appendix A saying how numbers are mapped, and reference Appendix C.
Peter Patel-Schneider: numbers are the most tricky point; someone reading Appenix a can really see how JSON-LD is an RDF dataset.
Peter Patel-Schneider: not just a link, but ???
… strings, true/false and lists are kind of alien to RDF (or just a bit skewed).
… It's not that it describes them in JSON terms as if they're divorced from the RDF description.
Manu Sporny: I'm fine with what we're discussion, but getting the text right is difficult. All agree that this is the direction, but the text is difficult.
… We're going to need to iterate on proposed spec text to try to get this right. Hopefully, the other things will be easier to get right.
Peter Patel-Schneider: I had specific spec-text.
Manu Sporny: yes, thanks, but we still need to iterate on it. I want to be sure that what we agree to do on the call will result in some spec-text we can agree upon.
Peter Patel-Schneider: what's wrong with the boiler-plate I provided?
Manu Sporny: it's confusing when the lexical and value spaces are different. For boolean it's true/false in JSON, and true/false/0/1 in RDF.
… We can't say there's full alignment.
Markus Lanthaler: we can say that true/false map to the xsd:boolean value space.
Peter Patel-Schneider: I probably wouldn't go that far, but I'd be happy with that.
… We're saying how to view these JSON-like things as RDF-like things.
Markus Lanthaler: would it be okay if we did this in Appendix C and link from A or should it be in A?
Peter Patel-Schneider: Appendix A says data model; if you say that the data model for JSON-LD has as values 5 different things, then you're saying there are 5 separate things You need something to speak to the fact that there are really only 2 kinds of things in the value space.
Markus Lanthaler: meaning numbers, true, false, strings are all typed values.
Peter Patel-Schneider: right now, it seems that are 6 different things in the JSON-LD value space.
Markus Lanthaler: in JSON they are distinct.
Dave Longley: Appendix A describes the RDF data model, not the JSON data model. We're not linking them together. Peter's point is correc,t we need to describe the RDF value and say how JSON values map.
Peter Patel-Schneider: This might okay, but I'm starting to get a bad feeling again.
… I thought we were aligning things, now were not?
Manu Sporny: no, we are, but the data model section has become quite pedantic. There are places where different people are concerned about fudging different definitions.
… Part of that issue is that JSON doesn't have a data model itself, so we need to interpret it.
… The parts that are different are where people disagree that there is a 1:1 mapping to RDF.
Manu Sporny: there's a lack of agreement over JSON-LD lists, for example.
Peter Patel-Schneider: I proposed spec text, for which some of the technical details are wrong, but I proposed a general phrasology
Manu Sporny: we agree with that, but we need specific text now.
Peter Patel-Schneider: apparently, I can't produce that, as I lack the experience (sic)
Manu Sporny: I think we've don't about as much as we can for alignment.
Peter Patel-Schneider: I've pointed out where I think changes need to be made, and provided spec-text. Certainly, the one for numbers needs to be modified.
… Let's try for true/false first.
Markus Lanthaler: manu, you might not have seen Peter's recent emails. We're very close.
Manu Sporny: The summary can't be informative, because we use RFC keywords all oer.
… I feel that the short-hand is a bit hand-wavy, but I'm fine with it. I don't have a better proposal.
Markus Lanthaler: my proposal would be to clarify in Appendix C
Peter Patel-Schneider: my point is that somewhere when discussing JSON-LD values, there needs to be something to say that they're not 6 different types of things.
Markus Lanthaler: what if we say JSON-LD values map to RDF literals, as defined in Appendix C
Peter Patel-Schneider: If they don't fit in the RDF model, they're wrong.
… Mapping indicates you're going between two different things. You could say "shorthand for"
… I'd be happier with "is", but "short hand" would work; it is vague but corresponds to reality.
Dave Longley: Can we say "interpreted as"?
Peter Patel-Schneider: that would work.
Markus Lanthaler: I'm not too happy with "Most types in typed values are XML Schema 1.1 Datatypes [pointer
to document"
Peter Patel-Schneider: I agree that it's wrong to put in a spec, but may be true in practice.
Manu Sporny: could we say often?
Markus Lanthaler: I'd say leave it out.
Peter Patel-Schneider: Okay, leave it out.
Manu Sporny: for lists, I'd be fine as "interpreted as"
Peter Patel-Schneider: with an informative pointer to RDFS
Markus Lanthaler: should we say mapped?
Manu Sporny: I think interpreted is the right language.
Peter Patel-Schneider: I think that's all the changes.
… I don't see any show stoppers for this late in the process.
Manu Sporny: I'll apply what we just discussed to the spec, and hopefully we'll be done with this issue.