- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 19 Mar 2013 12:06:39 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
The minutes from today's telecon are now available.
http://json-ld.org/minutes/2013-03-19/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-19
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0029.html
Topics:
1. ISSUE-224: Sandro Hawke's JSON-LD syntax spec review
2. ISSUE-222: David Booth's JSON-LD syntax spec review
3. ISSUE-230: Charles Greer's JSON-LD syntax spec review
4. ISSUE-223: JsonLdOptions base vs. @base
5. ISSUE-231: JSON-LD in HTML
6. Last Call timeline
Resolutions:
1. Add the JSON-LD in HTML feature to the JSON-LD Syntax
specification without support for @data-context. We are still
discussing @data-context and the danger of it forcing a JSON-LD
initial context.
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Markus Lanthaler, Gregg Kellogg, Dave Longley,
Niklas Lindström
Audio:
http://json-ld.org/minutes/2013-03-19/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Any changes to agenda?
Manu Sporny: Maybe we want to move the JSON-LD in HTML
discussion to the end since Niklas isn't here yet.
Topic: ISSUE-224: Sandro Hawke's JSON-LD syntax spec review
https://github.com/json-ld/json-ld.org/issues/224
Manu Sporny: Markus, mind taking us through this issue?
Markus Lanthaler: yep... Sandro thinks using @graph to specify
the default graph is confusing. He thinks having an array where
the first object is the context and all subsequent objects have
the context applied.
Gregg Kellogg: that can have strange effects down the line, if
you have multiple objects of a property, you'd think that context
would apply to subsequent objects in an array. If you had an
object that /only/ contained contexts.
Dave Longley: Yeah, we discussed this a long time ago. If you
have data in compact form, you can't check lengths of arrays...
you have to look through the entire array to see if there is a
context there.
Markus Lanthaler: We've had this question several times now...
it's not that common that you have an array at the top-level. In
some cases, it's a security vulnerability.
Markus Lanthaler: You can easily alias "@graph" to "data". When
we expand, we always expand it to an array at the top level.
Gregg Kellogg: There is is interest in using a canonical JSON-LD
representation as an array. In JSON-LD in HTML stuff, that's
something the supporters see as happening... they think it's not
well understood by their community. But an array of objects
would.
Markus Lanthaler: If you look at all web apis out there, there's
always an object at the top level ... not an array.
Manu Sporny: i agree with markus, there are very few examples of
an array being at the top-level in APIs [scribe assist by Dave
Longley]
Gregg Kellogg: Yeah, maybe if we show an example with @graph
aliased to data'
Markus Lanthaler: Maybe we can do that in that example.
Manu Sporny: I think that sandro's comment may have more to do
with unfamiliarity with how JSON is used in the wild, i haven't
seen people use JSON in the wild all that much with arrays being
at the top-level coming back from API calls, etc [scribe assist
by Dave Longley]
Manu Sporny: I don't think people that author JSON on a regular
basis typically have objects at the top-level [scribe assist by
Dave Longley]
Manu Sporny: typically, i'd expect to see something like this in
a search result [scribe assist by Dave Longley]
Markus Lanthaler: but then you'd also see things like "how many
results you got back", etc. and those would be top-level
properties [scribe assist by Dave Longley]
Markus Lanthaler: and then the array would be underneath another
property [scribe assist by Dave Longley]
Manu Sporny: yeah, we should create an alias example using
"results" or something [scribe assist by Dave Longley]
Manu Sporny: so people can see how that may work [scribe assist
by Dave Longley]
Markus Lanthaler: that would be dangerous because it would
affect the default context [scribe assist by Dave Longley]
Manu Sporny: i'm not saying do that, just do an example in the
spec [scribe assist by Dave Longley]
Manu Sporny: of using an alias here [scribe assist by Dave
Longley]
Gregg Kellogg: maybe also add a note asking for feedback for
this use case [scribe assist by Dave Longley]
Markus Lanthaler: Next up - data indexing.
Markus Lanthaler: Sandro feels it's pretty weird but fairly
harmless. He thinks we can index data by an arbitrary property?
Markus Lanthaler: We've discussed this before, it adds a bunch
of complexity. With Data indexing it's about representation of
metadata... I would say we do nothing here.
Markus Lanthaler: having arbitrary properties as indexes is too
complex for 1.0.
Dave Longley: I agree as well.
Gregg Kellogg: Yeah, agree.
Dave Longley: One request for this feature didn't want the RDFa
data in the index - it meets the use case that was there for it.
Gregg Kellogg: The only thing I worry that we're missing is the
other pattern from these indexes where you have a top-level key
in which the data contains an array of properties. The Microdata
JSON is an example of this, where you have id at the top and then
properties, and the value of properties is the value of all of
the properties.
Gregg Kellogg: There is a case where you might fold these in,
I've seen this in other places as well. I'm a bit concerned that
we will wish we had that.
Markus Lanthaler: I think the reason for that is because they
don't have a way to namespace properties like JSON-LD...
Gregg Kellogg: Unless the identifier key could be re-used... My
concern is that Microdata is something we thought we'd be able to
handle at some point through these mechanisms, but we never came
back to it.
Markus Lanthaler: There is always the possibility of having a
pre-processing step.
Manu Sporny: So, we're doing nothing to change the spec in this
case - the feature is good as designed.
Markus Lanthaler: Sandro talking about the data model section,
he found it very confusing even though he is familiar with RDF
Concepts.
Markus Lanthaler: It's a bit strange since most of these
statements have been copied almost directly from RDF Concepts. He
asked if we could drop this section, however, the RDF WG
requested that we add this section in here.
Markus Lanthaler: Instead of re-defining our own data model, we
could just say that it's the RDF data model, but we don't place
restrictions on where blank nodes are usable.
Manu Sporny: it may be that sandro knows too much about the RDF
data model and he may not be taking the text at face value, but
that's just trying to get into his head which i shouldn't be
trying to do [scribe assist by Dave Longley]
Manu Sporny: Ok, so we're not changing this section because the
RDF WG asked for it, it's clear, concise and nobody in this group
thinks we should change it.
Markus Lanthaler: Next up is normative non-normative labels are
applied inconsistently.
Markus Lanthaler: we discussed this, but in respec, we'll
relabel as appropriate.
Markus Lanthaler: Example 62:
http://json-ld.org/spec/latest/json-ld-syntax/index.html#turtle
Markus Lanthaler: The example is correct - it's what we say in
the spec and it's quite obvious that we define a prefix in
JSON-LD and Turtle. No change.
Markus Lanthaler: In the IANA considerations we have the profile
IRI... Sandro didn't apply what the profile IRI applies to. What
does the 'SHOULD' Apply to? requests or responses?
Markus Lanthaler: I think it works. He also said he thinks it
should work like normal content negotiation. It's an optional
parameter, if you can't expand it on the server, you return what
you can do.
Manu Sporny: i think it would help if we explained a little bit
more in that section about what should happen [scribe assist by
Dave Longley]
Manu Sporny: basically put a note in with sandro's concern where
we basically say "if you request expanded form and the server
can't expand it then it doesn't have to" [scribe assist by Dave
Longley]
Markus Lanthaler: Some references are out of date, like
TURTLE-TR and reference style isn't correct... we'll have to fix
this before we go to LC. Especially since Turtle keeps changing
state.
Manu Sporny: let's just call it TURTLE-REC and make the change
and assume it will go to REC before JSON-LD does [scribe assist
by Dave Longley]
Manu Sporny: these are very small editoral changes and i'm not
that concerned about it [scribe assist by Dave Longley]
Markus Lanthaler: they are even informal references [scribe
assist by Dave Longley]
Gregg Kellogg: i think RDF-CONCEPTS is a normative link in the
JSON-LD API spec [scribe assist by Dave Longley]
Manu Sporny: i guess that's not too much of an issue since it's
in the same working group [scribe assist by Dave Longley]
Manu Sporny: in the worst case the JSON-LD API spec is held up
while the RDF-CONCEPTS spec goes to REC [scribe assist by Dave
Longley]
Markus Lanthaler: next sandro suggests moving RDF conversion to
the syntax spec [scribe assist by Dave Longley]
Markus Lanthaler: He also sent a second e-mail about the
conversion descriptions - he wants an informative description
about the process of turning JSON-LD into RDF and vice versa.
Gregg Kellogg: We'd need to cover the expansion and flattening
algorithms.
Gregg Kellogg: i don't think he wants to move the whole
algorithm, but maybe a brief description of how they work [scribe
assist by Dave Longley]
Gregg Kellogg: I think they want one place where you can go to
figure out how JSON-LD can represent RDF and vice versa.
Markus Lanthaler: The whole syntax spec is about that - how the
context works, how nodes are expressed.
Gregg Kellogg: We could say something about the general process
of transforming JSON-LD to RDF has to do w/ expanding/compacting
the document... and then you can translate those statements to
RDF.
Markus Lanthaler: As soon as we do that, people are going to ask
about the algorithms.
Gregg Kellogg: we refer to the API spec.
Gregg Kellogg: We can explain that expanding is the process of
removing the context, flattening is ordering everything in a flat
sequence, then you can easily go to RDF.
Gregg Kellogg: We can show how the transformation happens.
Manu Sporny: As long as we can keep it short, that would be fine
with me.
Gregg Kellogg: I'll write that section.
Markus Lanthaler: Sandro wanted to add to the conformance
section: a JSON-LD Expander, JSON-LD COmpacter, JSON-LD
To-RDF-Converter, JSON-LD From-RDF-Converter.
Markus Lanthaler: This is about the syntax specification, not
the API specification.
Manu Sporny: So, no change.
General agreement to no change to the conformance section.
Markus Lanthaler: we can talk later about maybe adding that to
the API spec instead, it doesn't belong in the syntax spec
[scribe assist by Dave Longley]
The group feels it has addressed all of Sandro's comments.
Topic: ISSUE-222: David Booth's JSON-LD syntax spec review
https://github.com/json-ld/json-ld.org/issues/222
Markus Lanthaler: His first point is that JSON-LD should be an
RDF syntax - same data model, same semantics as other
serializations.
Manu Sporny: We've had a very long discussion about the
differences in the data model - the only distinction is blank
nodes, right?
Markus Lanthaler: Yes, only difference.
Gregg Kellogg: In this regard, we're not too different from
notation 3 for properties. For graph labels, it has a different
context.
Dave Longley: He effectively asks to change the RDF specs first,
however, there is disagreement over where the future should go.
We would prefer it to go into the RDF spec, but that's not
happening right now.
Markus Lanthaler: We've discussed all of this several times, not
even the RDF WG has a clear position about the additions to the
data model that JSON-LD has... re-opening the discussion again
isn't productive at this point in time. It is a super-set, we
discussed with the RDF WG, they accepted it, we clearly
documented the differences, we can't do much more than that.
Markus Lanthaler: We would like to keep JSON-LD as-is.
Manu Sporny: I agree.
General agreement from the group that we're doing all we can to
address this point.
Markus Lanthaler: His second point is that JSON-LD should not
require that IRIs are de-reference-able. I find this a bit odd
since JSON-LD is about Linked Data and Linked Data is about
dereferenceable IRIs.
Markus Lanthaler: Besides, it's a SHOULD not a MUST, so it's not
a hard requirement.
General agreement from the group - no change, IRIs should be
dereferenceable.
Gregg Kellogg: We had these conversations a while ago, nothing
has changed.
Gregg Kellogg: Regarding JSON-RDF - that name was already taken
at the time.
Manu Sporny: Besides - this is more about Linked Data than it is
about RDF.
Dave Longley: This spec is about JSON in Linked Data... the name
is fine.
Gregg Kellogg: JSON-RDF exists, and application/rdf+json exists
- we can't re-use it.
Topic: ISSUE-230: Charles Greer's JSON-LD syntax spec review
https://github.com/json-ld/json-ld.org/issues/230
Markus Lanthaler: I responded to his issues.
Gregg Kellogg: He seems to be happy with the changes.
Markus Lanthaler: He did respond today about @base and @vocab
and how they're used in relation to relative IRIs. He
acknowledges that @base is marked as at-risk, he still sees the
risk with trying to do too much with expansion.
Markus Lanthaler: The other thing was mainly editorial, we
characterize JSON-LD as a serialization of Linked Data in JSON.
Markus Lanthaler: Not sure I understand him completely. He
thinks that RDF/XML could have benefited from a distinction.
Markus Lanthaler: So you could have multiple expressions of RDF
in JSON (flattened, expanded, re-framed, etc.)
Markus Lanthaler: One aspect of JSON-LD is serialization and the
other is authoring.
Markus Lanthaler: Before he realized that we had a flattened
form, he thought that JSON-LD has many of the same problems as
RDF/XML... but now that he knows about flattened form, you get
the data in a deterministic form.
Dave Longley: he was worried that with all the ways of
expressing the data, that it would be hard for an application to
find out where the data is... but that only solves some of the
"find the data" use cases.
Dave Longley: Unfortunately, some of this has to do with
framing, because it's not in the spec.
Gregg Kellogg: I think it's useful to have someone that made a
statement like this, some older RDF hats have said that we're
making same mistakes that RDF/XML did... but we do allow the data
to be modified and re-framed, which RDF/XML didn't do. That said,
I don't think this comment is really action-able.
Markus Lanthaler: I think the point he's trying to bring across
is that this isn't as much about serializing data, just
augmenting the data with a context so you can interpret it as
RDF.
Markus Lanthaler: You already have your JSON, you want to
transform it to Linked Data, you just add your context and almost
magically it can be interpreted as RDF.
Manu Sporny: That's a very good, concise statement - we should
say that in the spec.
Dave Longley: Yes, if it's not in the spec, it should be in
there.
Markus Lanthaler: We don't say that in the abstract/intro, we
probably should.
Markus Lanthaler: He's also worried about remote contexts.
Remote contexts are important, we have plenty of use cases for
them.
Gregg Kellogg: It's a bit different from RDFa - documents aren't
meaningless w/o them. In JSON-LD, documents are meaningless w/o
being able to dereference the remote context.
Gregg Kellogg: His point is that you don't know if the data
that's represented hasn't changed...
Dave Longley: You could run it through the normalization
algorithm to see if it's changed.
Gregg Kellogg: How would that work? Use E-Tags?
Dave Longley: It's gets pretty complicated. If the remote
context going away is a problem, you should cache or embed the
context.
Markus Lanthaler: If you include external files, this is an
issue on the Web. Like external javascript files.
Dave Longley: You could hash the external context and include
that hash.
Markus Lanthaler: Yes, there are lots of ways to avoid the
problem. In many cases, you have control over your context and
you can change it in lock-step. The advantages of having a remote
context outweighs the drawbacks.
Dave Longley: =)
Group agrees that it has responded to all Charles Greers
comments.
Topic: ISSUE-223: JsonLdOptions base vs. @base
https://github.com/json-ld/json-ld.org/issues/223
Markus Lanthaler: The question is what happens when the base is
a relative IRI?
Gregg Kellogg: Doing something to allow relative IRIs w/in the
document is useful, but otherwise, I can't think of why you'd
want base to be a relative IRI. Why isn't it just an absolute
IRI?
Gregg Kellogg: You can do this in Turtle, where statements
become accumulative, we could do that w/in JSON-LD - don't know
if that's an important paradigm.
Markus Lanthaler: HTML and Turtle supports relative IRIs, having
the empty string to say there is no base is a bit weird. It's
something that should be done at the API level, if you don't want
a base. The use case is to not change relative IRIs
duringcompaction/expansion/ etc.
Niklas Lindström: .. http://www.w3.org/TR/xmlbase/
Niklas Lindström: Trying to think of a use case where relative
base IRIs are useful.
Niklas Lindström: In general, what we should do is to make this
work exactly in the same way as it's treated in HTML, Turtle, and
XML - we should take care to do the same thing.
Dave Longley: So only difference between PROPOSAL 3 and PROPOSAL
4 - if PROPOSAL 3 is close to what we want, then PROPOSAL 4
enables two other features.
Markus Lanthaler: I'm concerned where the empty string is used
for base... in HTML you can have a relative base "" and in Turtle
as well.
Dave Longley: Proposal 3 does not allow relative IRIs.
Manu Sporny: It sounds like we agree that we should align with
HTML, Turtle and XML, but we don't know what they do?
Markus Lanthaler: Just checked HTML5 - it allows relative IRIs
for base, previous versions didn't.
Niklas Lindström: … json-ld fetched from
"http://example.org/some/other" , with a @context containing
@base: "/doc". I'd then expect base to be
"http://example.org/doc"
Dave Longley: What's the behavior when you don't set the base in
this case?
Dave Longley: If you have relative IRIs in the document and you
have no base, and you get a relative IRI, how does "../.."
change? Does it become just "/"?
Gregg Kellogg: I think it happens in the same way as any other
RDF serialization. When you join IRI segments, it results in the
IRIs being normalized, which includes removing dot-segments.
Dave Longley: does "../../foo" become "/foo" ?
Dave Longley: because i think that's unexpected when base is none
Markus Lanthaler: You can't have relative IRIs in a RDF
serialization.
Gregg Kellogg: Yes, but you can have it in a syntax.
Markus Lanthaler: Yes.
Markus Lanthaler: if you are not able to establish an absolute
base, we shouldn't try to resolve relative IRIs in the document,
you just leave them as-is.
Gregg Kellogg: if we do that, we'd be the only serialization
format that tries to go this far to explain why this happens.
Markus Lanthaler: We have to resolve this because we allow the
base to be set.
Dave Longley: It also affects normalization.
Manu Sporny: Yes, we need to resolve this issue.
Gregg Kellogg: Maybe this means that if you specify a base IRI
in the API, it must be an absolute IRI... in the absence of it,
you'd be left with a document that has relative IRIs in it.
Dave Longley: I think it's important that we say: If you do not
specify a base... what happens? Base doesn't exist - leave
relative IRIs alone? What happens if base is specified in the
document and it's relative? What happens when it's specified in
the API and it's relative? We need clear answers to these.
Gregg Kellogg: Maybe we should say it's unaltered.
Manu Sporny: Let's take this back to the JSON-LD issue tracker
and cover all corner cases and see if they apply to how HTML,
Turtle, and XML deal with these corner cases.
Topic: ISSUE-231: JSON-LD in HTML
https://github.com/json-ld/json-ld.org/issues/231
Gregg Kellogg: There are cases where expressing metadata in HTML
using either Microdata or RDFa is not feasible or has been shown
to be error-prone.
Gregg Kellogg: As an alternative way of doing this, the idea is
to put JSON-LD in HTML.
Gregg Kellogg: A process that conforms to this could extract the
content of this script tag and run it through the JSON-LD
algorithms. It could be used to easily extract anything - for
Turtle, it's for extracting RDF.
Gregg Kellogg: In addition, there is a strong desire to not
require boilerplate w/in the JSON - take JSON that came out of
some JSON-LD database, without adding a context to the content of
the script tag.
Gregg Kellogg: So, that's why @data-context is being proposed to
be used for this purpose.
Gregg Kellogg: This is a way of specifying an external context,
kind of like we do with link headers.
Gregg Kellogg: One of the advantages of @data-context is that
you don't have to be very explicit - as long as you can
de-reference it, if you can get to the context, you're going.
Manu Sporny: Any opposition to putting this into the spec?
Gregg Kellogg: This is an informative addition.
Niklas Lindström: I've seen some possible uses for this, I'm
still a bit uneasy about the feature, but it seems useful. Maybe
instead of an RDFa API, we can just read JSON out of the page.
Niklas Lindström: It's a good thing to have. Since Turtle has
it, it'll be nice to have this as well.
Gregg Kellogg: When I added support for this for Turtle in my
processor, I did it generically.
Gregg Kellogg: My own system, if it saw this, it would extract
the RDF and add it to the default graph.
Gregg Kellogg: I'd need to refine it, but it has some history.
Dave Longley: This would be useful for Web Applications, to get
them some initial data to start up.
Markus Lanthaler: Wouldn't you just assign it to a variable in
that case? That's another way to do it. I don't like that the
context is placed somewhere else.
Markus Lanthaler: I don't like that you can't cut/paste that.
Also, data-* isn't intended for that use. We also say in the spec
that the context has to be in the document if you're
usingapplication/ld+json.
Gregg Kellogg: I tried @vocab instead of @data-context - but got
push-back on that.
Gregg Kellogg: @vocab has similar behavior to @context.
Niklas Lindström: I don't quite agree with that. We took out
@profile in RDFa. They're not really isomorphic.
Gregg Kellogg: You're right, I'm not suggesting we use that.
Markus Lanthaler: Why can't we use @context in JSON-LD?
Gregg Kellogg: The companies that want this don't want
boilerplate - they feel very strongly about this. It's a small
concession, it's in the spirit of how we specify it in a Link
Header. I think it's reasonable for us to do. I have asked the
people that have been promoting this to be more vocal, but they
haven't done so yet.
Gregg Kellogg: if some of these issues are raised, maybe that'll
provoke a response.
Markus Lanthaler: My fear is that we now say that they should
use the @data-context attribute - you end up having JSON that
isn't JSON-LD, people may forget to create it. Then we get to the
point where we might have to pre-define prefixes.
Manu Sporny: Like Markus, I'm very concerned with people not
using @data-context and us having to make that an initial
context.
Dave Longley: I'm not too sure that boilerplate argument works
here - I don't know if we're solving anything either way. They
may not include the @context, they may not include @data-context.
Markus Lanthaler: At least we wouldn't be implementing something
new.
PROPOSAL: Add the JSON-LD in HTML feature to the JSON-LD Syntax
specification without support for @data-context. We are still
discussing @data-context and the danger of it forcing a JSON-LD
initial context.
Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: Add the JSON-LD in HTML feature to the JSON-LD Syntax
specification without support for @data-context. We are still
discussing @data-context and the danger of it forcing a JSON-LD
initial context.
Niklas Lindström: What about: <script
type="application/ld+json;context='http://example.org/context.jsonld'">
Niklas Lindström: We talked about allowing @context as an
optional parameter to the MIME TYpe a long time ago?
Niklas Lindström: Maybe we can do the above.
Manu Sporny: I think a lot of authors would mess that up.
Gregg Kellogg: It's worth discussing it in more depth.
Gregg Kellogg: Let me send that back to them and see what sort
of response I get.
Gregg Kellogg: That would also serve the same effect. It's
boilerplate, but maybe that would work.
Topic: Last Call timeline
Manu Sporny: We've finished all review comments, we'll fix up
the spec with the decisions we've made on those comments.
Manu Sporny: We'll get the JSON-LD Syntax spec into Last Call
after we get those changes in, hopefully there won't be a flurry
of new comments in the mean time.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/
Received on Tuesday, 19 March 2013 16:07:15 UTC