W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2013

JSON-LD Telecon Minutes for 2013-07-09

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 09 Jul 2013 16:52:06 -0400
Message-ID: <51DC77F6.6000102@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Gregg for scribing. The minutes from this week's telecon are
now available.

http://json-ld.org/minutes/2013-07-09/

Full text of the discussion follows including a link to the audio
transcript:

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-07-09

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0047.html
Topics:
    1. Blank nodes as predicates
    2. RDF Alignment Editorial Changes
    3. JSON-LD / RDF Alignment
Action Items:
    1. Dave Longley to post blank node predicates example to list.
Chair:
    Manu Sporny
Scribe:
    Gregg Kellogg
Present:
    Gregg Kellogg, David Booth, Markus Lanthaler, Manu Sporny, Sandro
    Hawke, Niklas Lindström, Dave Longley, Peter Patel-Schneider,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2013-07-09/audio.ogg

Gregg Kellogg is scribing.
David Booth:  I wanted to talk further about RDF term alighment
    … API doc requires some more updates.

Topic: Blank nodes as predicates

David Booth:  that was the only substantive lack of alignment
    between JSON-LD and RDF.
    … Markus and I have discussed on mailing list. I think we can
    do away with BNodes as properties in JSON-LD without any
    significant loss.
Markus Lanthaler:  we've discussed it quite a lot already, and
    have always concluded that we want it in JSON-LD. Nothing's
    really changed.
Manu Sporny:  My concern is that we've discussed that it's
    impossible to express...
    … You could always skolumize keys to turn them into RDF, but
    that would change the meaning of the JSON, but making internal
    things external.
    … I'd be concerned with removing them, because then JSON-LD
    would not be capable of expressing JSON.
    … DBooth is partially correct, that it wouldn't cause any real
    damage, because we've backed off a bit.
Manu Sporny:  bottom line, bnode predicates are there so we can
    express a JSON document.
    … As JSON-LD is built on JSON, this would be silly.
    … I think this will be enough for people to move to bnode
    predicates in the future, and maybe RDF 2.0 will have them.
David Booth:  that's not what I saw in markus' example; it was
    clear that relative URIs could have been used just as well, and
    may be better
    … I haven't seen any motivating use case that requires them.
    … I think that prohibiting bnodes as properties is better than
    skolumnized ids.
David Booth: Example from Markus:
    http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0019.html
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:
    http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0019.html
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.

Topic: JSON-LD / RDF Alignment

Peter Patel-Schneider:  no IRC, unfortunately.
    … Unless someone has a free node HTTP relay
http://webchat.freenode.net/?channels=json-ld
http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0233.html
Manu Sporny:  I attempted to update the JSON-LD syntax spec with
    feedback from pfps and dbooth
    … Peter's not satisfied quite yet, so this discussion is to
    help resolve that
Peter Patel-Schneider:  In my opinion, the most recent changes
    are a big step in the right direction.
Markus Lanthaler: I've updated the data model to link to the
    definitions in RDF Concepts for those that haven't seen it yet:
    http://json-ld.org/spec/latest/json-ld/#data-model
    … 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
Markus Lanthaler: http://www.ietf.org/rfc/rfc4627.txt
    … 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
Markus Lanthaler: http://json-ld.org/spec/latest/json-ld-api/
Markus Lanthaler:
    http://json-ld.org/spec/latest/json-ld-api/#data-round-tripping
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.
Markus Lanthaler:
    http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0105.html
Markus Lanthaler:  Asterisks mark changes
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.
Dave Longley: https://github.com/json-ld/json-ld.org/issues/264

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Tuesday, 9 July 2013 20:51:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:30 UTC