- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 10 Jan 2012 14:27:17 -0500
- To: Linked JSON <public-linked-json@w3.org>
The minutes for today's call are now available here:
http://json-ld.org/minutes/2012-01-10/
Full text of the discussion follows, as well as a link to the complete
audio transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-01-10
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0001.html
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler,
David I. Lehn
Audio:
http://json-ld.org/minutes/2012-01-10/audio.ogg
Manu Sporny is scribing.
Topic: Specs and Test Suite Update
Gregg Kellogg: In terms of Editors Drafts - we should push out
another version of the specs.
Gregg Kellogg: I think we're close to stability w/ the syntax -
main thing on the board is changing @literal to @value.
Gregg Kellogg: Other than that, we may be converging on the
syntax.
Niklas Lindström: I finally got around to adding support for
JSON-LD in RDFExtras... complementary lib to RDFLIB in Python...
doesn't bring any news issues today, but am getting a feel for
the details of the spec.
Niklas Lindström:
http://code.google.com/p/rdfextras/source/browse/?name=jsonld#hg%2Frdfextras
Niklas Lindström: I did notice that the tests are a bit strange,
changed SPARQL to TURTLE examples... I do back-and-forth
conversion - may want to look into that.
Gregg Kellogg: Is this in the source repository?
Niklas Lindström: Not yet.
Manu Sporny: Test suite looks great... we will probably keep
using that... you have to implement a test runner for it?
Gregg Kellogg: Yes, one caveat is that you need SPARQL to do
some comparisons... we could turn it into normalized JSON and
just compare that.
Gregg Kellogg: SPARQL is only used for RDF conversion tests...
Gregg Kellogg: You could go from JSON-LD - RDF - JSON-LD -
normalize and compare that, but that's a bit complicated.
Manu Sporny: Do you know if the JavaScript SPARQL
implementations are fairly complete?
Gregg Kellogg: Haven't had the time to look in depth.
Niklas Lindström: Parsing JSON-LD then serializing to normalized
JSON structure is complex... you don't really know where in that
chain those things fail. SPARQL implementations are quite complex
as well... perhaps we should look into RDF triple set comparison.
There is a fairly understandable implemention of it in RDF lib.
Gregg Kellogg: I have one of those in Ruby as well... doing
Jeremy Carroll's algorithm is not simple. It's important to have
- triple comparison is simple to do... understandable why you
can't do that for RDFa... but for JSON-LD, that may be possible.
Topic: ISSUE-43: Use of IRIs and CURIEs as @context keys
https://github.com/json-ld/json-ld.org/issues/43
Gregg Kellogg: The issue is that if you are serializing from RDF
into JSON-LD, where you have namespaces, but you don't have
terms, you can easily create CURIEs, but you'd also like to have
the full coercion expressivity.
Gregg Kellogg: For example, you want to be able to say that a
property is a certain datatype...
Gregg Kellogg: In my implementation, anything that can be an IRI
in the key position in the context can be a CURIE or an IRI...
that allows you to do useful things, where terms can have
coercion properties.
Manu Sporny: Spoke with Dave Longley about it, he's for it. So
am I, seems like a useful feature.
Markus Lanthaler: You could have several definitions for the
same term... you could have 3 different URIs for the same term
and 3 different datatypes - we'd have to specify how to merge
those different definitions together.
Gregg Kellogg: my table is defined w/ IRIs as keys, so this
can't happen.
Gregg Kellogg: I think that if you end up setting a term to a
different IRI, the algorithms won't invoke that mapping.
Gregg Kellogg: If we split the key on a colon, you look up the
prefix... you get the IRI... if it is an IRI or CURIE, you just
get the term part of it.
Markus Lanthaler: Nevertheless, if you have two URIs defined,
you have to figure out how to set them.
Gregg Kellogg: I don't know if we want to specify the
behavior...
Niklas Lindström: I think there might be a problem here, one
thing that strikes me is that we probably should that there is a
precedence rule... there should probably be the possibility to
define two different terms for the same IRI, but with different
coercions.
Manu Sporny: I think we should kick out an error if somebody
tries to set an IRI w/ the CURIE mechanism.
Niklas Lindström: I think that's fine.
Niklas Lindström: I think that we should expand CURIEs in
context quickly.
Gregg Kellogg: I agree that the only time an @id should be set
is when it's used as a term.
Gregg Kellogg: We should say that coercions map to the expanded
version of the terms... that is what is used when we do coercion.
Markus Lanthaler: If you do that on an expanded IRI, it would
prevent the use of two different terms with two different
datatypes.
Markus Lanthaler: This is mainly for when you generate JSON-LD
from RDF... when you automatically serialize RDF, you don't know
if every property will use the same datatype.
Discussion about how the @context is built when processing terms
and CURIEs
Markus Lanthaler: The only good use case for this is when you
convert from RDF to JSON-LD... it's arguable if you need this
type of optimization. Do we need this feature, not that trivial
to implement this feature?
Niklas Lindström: I kind of agree with Markus - I think that
when you're automatically serializing RDF and you use prefixes
for one... coercing the values for one feels half-baked to me.
Niklas Lindström: I'm a bit wary of it... in RDF, you can have
all kinds of values for a certain property - you could have one
value which is a language-tagged value, something else that is an
xsd:string, something else that is a dateTime.
Niklas Lindström: I prefer to defer this, but would like to hear
Gregg's use cases on this.
Gregg Kellogg: There are a number of cases where this may be
useful - it avoids a great deal of work where you're describing
things in a context. Cases for doing coercion of CURIEs are
focused on converting RDF to JSON-LD - my processor creates
conversion rules when they lead to a net reduction in size.
Gregg Kellogg: For example, if all dc:created are dates, then I
can compress the document.
Markus Lanthaler: The context is about defining terms and
prefixes.
Gregg Kellogg: I think that it's natural that people will try
this - author's will do this, no good reason not to support the
use case.
PROPOSAL: Allow CURIEs as @context keys.
Manu Sporny: +0.5
Gregg Kellogg: +1
Niklas Lindström: +0.1
Markus Lanthaler: -0.5
David I. Lehn: +0.5
Manu Sporny: Let's kick this back to the mailing list... Gregg,
could you do a concrete proposal on this?
Niklas Lindström: I remember seeing an experiment in JSON with
using prefixes, not from this community, but they were using
something like CURIEs.
Niklas Lindström: So, it might be useful...
Topic: ISSUE-48: Rename @literal to @value
https://github.com/json-ld/json-ld.org/issues/48
Markus Lanthaler: Fairly trivial change - rename @literal to
@value... @literal is coming from an RDF background and most
developers are more familiar with the term 'value' than they are
with 'literal' - because a 'literal' could also be numbers.
Markus Lanthaler: @value would be better for developers - it
would make it easier to understand for developers.
Gregg Kellogg: I think that literals are a common term in most
programming environments... they mean something different from
value - values have both simple and complex data structures...
literals imply something that is not a structured element itself.
integers, strings, dates - scalar might be a better term?
Niklas Lindström: The thing is that you have the value and the
datatype... literal is the result of that thing.
Markus Lanthaler: Yes, literal is the combination of the
datatype and the thing that we need to name... value could work.
Markus Lanthaler: Lexical representation... lexical, string, may
work.
Markus Lanthaler: @value is just a token anyway...
Manu Sporny: Dave Longley is in favor of @value, so am I. It
resonates more with Web developers than @literal.
Gregg Kellogg: I think RDF people might like @value more...
@value might work on a number of different communities.
PROPOSAL: Rename the @literal keyword to @value.
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: Rename the @literal keyword to @value.
Topic: ISSUE-42: Distinguishing a JSON-LD frame from a JSON-LD document
https://github.com/json-ld/json-ld.org/issues/42
Manu Sporny: JSON-LD frames are not JSON-LD documents... we may
want to just make them regular JSON objects.
Niklas Lindström: Has anybody thought about using the @frame
keyword in a JSON-LD document?
Niklas Lindström: I may want to publish frames... they would
constitute documentation for me... in those scenarios, I think
that @frame would be helpful in those scenarios.
Niklas Lindström: If we're worried that people look at frames
and confuse them with instance documents, we may want to add
@frame.
Gregg Kellogg: I think we went through the same discussion with
@context... so we decided that @context documents start with a
@context key.
Gregg Kellogg: if we are going to have a data structure that has
a frame, we're inevitably going to need to get that data from an
IRI.
Gregg Kellogg: I don't have a way to express a frame inline,
very effectively. The fact that the document is part of JSON-LD
does argue that they should have something that has a JSON-LD
MIMEType...
Gregg Kellogg: This is very symmetric with the way we deal with
@context.
Markus Lanthaler: I don't think that frames are the same as
@context... they are quite different in my opinion. You include
the @context directly in a JSON-LD document, you'd never do that
with a frame. The Frame is a distinct concept, separate from the
document.
Markus Lanthaler: The cleanest solution would be to create a new
MIMEType for JSON-LD frames.
Markus Lanthaler: Frames are kind of a query language for JSON-LD
Niklas Lindström: I'm a bit wary about MIMEType proliferation...
people screw it up in usage... people are more prone to look at a
document and think it looks like JSON-LD, than look at the
MIMEType.
Niklas Lindström: We may want to specify @frame to make it
explicit.. @frame should not be in the JSON-LD spec... it should
be in the API spec.
Manu Sporny: There are two issues here - follow-your-nose and
helping newbies recognize the difference between a JSON-LD
document and a JSON-LD frame. The first problem is addressed by
creating a MIMEType for frames. We don't know if adding @frame
will address the second problem. In the worse case, we add frame
and newbies still think it's a JSON-LD document and not a JSON-LD
frame. We may not even want a new MIMEType because nobody looks
at those, like Niklas said. JSON-LD frames don't look like
JSON-LD documents, really.
Markus Lanthaler: Yes, but not having a MIMEType prevents people
from doing things like having different icons, using different
editor's for frames, etc.
Niklas Lindström: I still think that JSON-LD frames look very
much like JSON-LD documents.
Gregg Kellogg: I think that just using a plain JSON document
fails the follow-your-nose test... it needs to be a JSON-LD frame
MIMETYPE or a subtype of JSON-LD document
Gregg Kellogg: There is some danger of making it too much like a
JSON-LD document, but the contents are explained in the spec. You
can clearly find out the meaning of that by looking at the
specification.
Long discussion about whether or not @frame would solve the
problem of confused developers - fair arguments that it would and
wouldn't.
Niklas Lindström: Look at the library example - the frame looks
exactly like a JSON-LD document:
http://json-ld.org/playground/playground-examples.js
Markus Lanthaler: We could put the @frame beside the @context?
(a) { "@frame": { "@context": "....", "query": "..." } vs. (b) {
"@context": "....", "@frame": "query..." }
Manu Sporny: Let's straw-poll to see if we want to support a
MIMEType for JSON-LD frames...
PROPOSAL: JSON-LD frames should have a MIMEType, which is
distinct from JSON-LD documents.
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
Niklas Lindström: .. like "application/jsonldframe+json"
David I. Lehn: I can see people just wanting to use regular json
mimetype for all these docs
Niklas Lindström: David Lehn, I believe so too
RESOLUTION: JSON-LD frames should have a MIMEType, which is
distinct from JSON-LD documents.
Gregg Kellogg: application/frame[+-]ld+json
Gregg Kellogg: The syntax document is almost done, we should
figure out what our plan is for the next couple of months... send
something to the mailing list, Manu.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
Received on Tuesday, 10 January 2012 19:30:23 UTC