- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 09 Jul 2013 16:52:06 -0400
- 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