- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 15 May 2012 22:51:48 -0400
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Gregg for scribing! The minutes from today's call are now
available here:
http://json-ld.org/minutes/2012-05-15/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-05-15
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0005.html
Topics:
1. Finishing up the JSON-LD Syntax document
2. ISSUE-100: Should the JSON-LD API have a "mode": "strict"
flag?
3. ISSUE-116: Introduce @extension keyword?
Resolutions:
1. JSON-LD will support a JSON-LD Processor Event mechanism
that will report certain events (to be decided later) via a
callback given through JSON-LD API calls.
2. The JSON-LD Processor Event callback would be registered
for every JSON-LD API call, and would provide the type of event
and the data associated with the event for the callback. This
mechanism would be used to report potential errors, warnings and
when the processing of the document was complete.
3. When a JSON-LD processor processes input that would result
in an exception, it should instead call the JSON-LD Processor
Event callback with data concerning the issue that was detected.
4. Do not support the @extension keyword at this point in
time.
Chair:
Manu Sporny
Scribe:
Gregg Kellogg
Present:
Gregg Kellogg, Manu Sporny, Markus Lanthaler, Niklas Lindström,
David I. Lehn
Gregg Kellogg is scribing.
Topic: Finishing up the JSON-LD Syntax document
Manu Sporny: need to put some last changes in the Syntax spec
before submitting to the RDF WG.
… Is it ready? Is there more cleanup necessary.
Markus Lanthaler: the last issue on the agenda may be syntax
related.
… there's also the formally defined grammar.
Manu Sporny: we could create a section for the grammar and
finalize after it goes to the WG.
… @type could also be discussed after it's presented to the
RDF WG
… when presenting, we should know how to resolve outstanding
issues.
… we should add the two open issues as issue markers in the
spec.
… then we can ask for comments and push to an FPWD through RDF
WG.
Niklas Lindström: what is the process once it goes into the RDF
WG.
Manu Sporny: typically, they would create a task force to
propose something to bring back.
… we could say we believe it's ready to be formalized and
published as a rec-track doc.
… we'd try to get all of us in the RDF WG so that we could
discuss it.
… almost immediately, do an FPWD, and the WG can raise issues
on the spec.
… then there is a request for implementations.
… have to figure out how the CR phase should go.
… Then PR and REC. Hopefully a tighter release schedule than
RDFa.
Niklas Lindström: do we want it so finished that there won't be
any significant discussion?
Manu Sporny: the people in this group need to be on the same
page before going in to avoid fracturing within the WG.
… if we had a fundamental disagreement about what @graph
means, that could get dragged out.
… it could help focus their discussions, or it could blow
things up.
… If it were not working well in the RDF WG, it could go to a
different group, or that a new one could be created.
… however, it would be good to have more eyes on the work than
a new group might bring.
Markus Lanthaler: if we go into RDF WG, is there a mechanism to
move it someplace else?
Manu Sporny: yes, that happened with HTML+RDFa, for example.
… this is often done when things get "stuck". In the worst
case, there's a spec out there that people can use.
… less likely to be an issue about JSON-LD than there was
about HTML+RDFa.
Niklas Lindström: we've seen some different perspectives on how
people want to use JSON-LD, but I think we've settled on the
general "shape".
… There might be some issue with the overloaded meaning of
@type. I probably wouldn't mind re-introducing @datatype, but we
might try to make the current use more convincing.
Manu Sporny: we might fixate on this as being a big deal, but
that it's not really the issue after all.
… there's no-one in the group that is disingenuous. If there's
a lot of negative feedback, we might regroup.
… a couple of people in the group have read it, and most of
the comments have been grammatical, not technical.
Markus Lanthaler: we would present the syntax and not the API
document, right?
Manu Sporny: yes. We're not putting out the API document yet,
because we want to see how people actually use it.
… this allows people to see that the syntax is solid first.
Niklas Lindström: framing is important. we should have some
slack.
Gregg Kellogg: I think people may have questions about how the
RDF conversion works - not having an API spec to reference could
create more issues. [scribe assist by Manu Sporny]
Manu Sporny: the docs there, it's just that there might not be a
normative link.
… we could say the reasons whey there is not a normative link,
but continue to reference it.
… this allows us to focus on the syntax, and not get into more
complex areas until it's more widely used.
Gregg Kellogg: One of my concerns is about named graphs - it
seems like as they go on, they create more issues. [scribe assist
by Manu Sporny]
Gregg Kellogg: If JSON-LD goes in, and there are various issues
around a non-normative API - it may cause us to spin. JSON-LD
might be different as it doesn't have to do with core semantics -
doesn't need to be a pedantic discussion. [scribe assist by Manu
Sporny]
Manu Sporny: that's why we all need to be on the same page.
… the way we address that is to describe our process for
creating what's there. The core semantics can be figured out
later, by a different group of experts.
… up until now, they haven't had a concrete need for it to be
done. JSON-LD puts some pressure on that takes a stand.
… we can then see if this allows consensus to form.
Manu Sporny: we're splitting hairs on implementation details in
the API; we're in good agreement about the core principles.
Markus Lanthaler: I t think we have general agreement; we're
down to possible changes in expanded form.
Niklas Lindström: possible reservation about issue #120, which
could be a hint that overloading @type is problematic
… for me, datatype has some meaning separate from type.
David I. Lehn: should we put more work in to a primer?
Manu Sporny: ideally, we'd have a primer, which is a quick read.
… the beginning of the syntax doc is something like a primer,
though.
David I. Lehn: my approach was that of the novice JSON
programmer, who wants to know how to turn is date into Linked
data.
Manu Sporny: we could put up a wiki, but then it doesn't get
edited.
… everyone here has commit rights to the repo, so we should
just put up a page.
Gregg Kellogg: We may just want a portion of the website that
has examples - just examples that they can browse through and see
things. [scribe assist by Manu Sporny]
Niklas Lindström: I had some ideas, that are more like stories.
One would be a generalized approach for legal information.
Manu Sporny: let's create an examples page that could list a
bunch of examples, and then clicking on it could reach out to
JSON-LD.
Manu Sporny: plan of action to make one more pass through syntax
doc and tell the RDF WG we're ready to have it discussed there.
Manu Sporny: we would all transfer into the RDF WG, and the
community group would pretty much go away.
… Work would proceed within the RDF WG.
… if we're successful, we'll be the first CG to get a
rec-track spec out.
David I. Lehn: (we need a logo and t-shirts)
Markus Lanthaler: :-)
Topic: ISSUE-100: Should the JSON-LD API have a "mode": "strict" flag?
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/100
Manu Sporny: first question, have a strict more or validate
option in the API.
… second, if there is a mode, should there be just strict and
lax or strict, match and lax?
… strict raises errors on any errors.
… match would just drop problematic data
… lax would try to change things based on authors intent.
… a fourth option would be a lint option.
Markus Lanthaler: don't really see the need for these options.
JSON-LD isn't intended for human use, so there may not be anyone
to "see" that there's an issue. If we don't through an exception,
it could just be lost.
… we had said that JSON-LD should be as forgiving as possible.
Note sure what these modes do in algorithmic terms.
Manu Sporny: base concern is that we started out by saying that
it should be forgiving; this should be the default probably.
… in general, we want it to be forgiving; but there are cases
where having a forgiving process is not ideal; it could create
more complex code or allow bad data to be introduced.
… one of the reasons developers prefer JSON to XML is because
it's readable.
… key concerns: we'd burden a subset of developers. Some want
exceptions thrown when anything unusual happens. Others don't
really care about error cases.
Markus Lanthaler: if we're doing fromRDF and we get something
unusual (say "five"^^xsd:integer)
Niklas Lindström: .. <> dc:creator "Some Body" vs. <> dc:creator
[ foaf:name "Some Body" ]
Gregg Kellogg: if I was importing RDF data, and I had data that
didn't match what I expected, then throwing an exception in that
case might be useful. [scribe assist by Manu Sporny]
Gregg Kellogg: I might switch from "strict" to "lax" when I go
from development to production mode. [scribe assist by Manu
Sporny]
Niklas Lindström: Jena does seem to do some checking, and I've
used that to find JSON errors before.
… I would really make use of all three modes.
Manu Sporny: in HTML5 we learned that people use bad formats,
but people expect it to work.
Niklas Lindström: s/find JSON errors/find RDF datatype errors/
… people prefer something that recover when they can. This
says that strict mode shouldn't be the default.
… there are a subset of people that care about things that are
wrong.
Markus Lanthaler: we changed conversion of native types to just
fromRDF, so it's not as much of an issue.
Niklas Lindström: .. <> dc:created "today" => "created": {"@id":
"dc:created", "@type": "xsd:date"} => different effects depending
on mode
Gregg Kellogg: What the developer needs is potentially something
that we can't consider in this group - such as linting - that
should be done outside of this group. Maybe we want to be a bit
softer - "do stuff w/o any normative language on what should be
done". That gives implementers a hook to use that as a basis for
doing their own linters or pedantic checkers. [scribe assist by
Manu Sporny]
Niklas Lindström: this term would never be choosen in compaction
because the type doesn't match [scribe assist by Markus
Lanthaler]
Niklas Lindström: or are you talking about fromRDF()? [scribe
assist by Markus Lanthaler]
Gregg Kellogg: We want to give developers a hook to make
implementing this easier. [scribe assist by Manu Sporny]
Markus Lanthaler: we should come up with the list and decide
upon that.
Markus Lanthaler: ah, right. With this rule I think my case for
compaction is safe. in fromRDF, I think if no term is found, it's
ok if the full iri fordc:created is used with an expanded literal
form. [scribe assist by Niklas Lindström]
Gregg Kellogg: Strict mode flag when applied to anything that
uses expansion, would warn about ignored data - either properties
or data. Strict mode flag in compaction would do the expansion
and report on problems applying the context to the data. In
framing, it would warn you about syntax issues in the frame in
addition to issues inexpansion/compaction. [scribe assist by Manu
Sporny]
Gregg Kellogg: Data type checking comes in when you go from RDF
into JSON-LD - and depends on how you do the translation. If
booleans/doubles need to be converted into native types. If they
ask that "five" be transformed intoxsd:integer, but they cannot
be translated into native form. [scribe assist by Manu Sporny]
Markus Lanthaler: I see the use case in from RDF
Manu Sporny: What happens if you do this - "@id": 5 [scribe
assist by Manu Sporny]
… this could warn about native datatypes which don't match the
lexical representation. I don't see the value for compaction,
expansion, framing.
Manu Sporny: It would be very bad for us to error out on simple
issues like "@id": 5 - that's what XHTML1 did and it didn't solve
any issues. [scribe assist by Manu Sporny]
Gregg Kellogg: RDFa does this via processor graphs - don't know
if we want to introduce this concept to JSON-LD. [scribe assist
by Manu Sporny]
Gregg Kellogg: It's pretty clear to me that we need a flag.
There are some things where we found that we need it. Processors
should do "best-effort" when producing JSON-LD. Maybe there is a
callback instead of an exception mechanism. [scribe assist by
Manu Sporny]
Manu Sporny: I like that - instead of a flag, the APIs take an
extra callback - "onError()"? [scribe assist by Manu Sporny]
Gregg Kellogg: You could have a single closure associated with
the data - and the program would halt if the callback responds
back with a "false" - which means "stop processing". [scribe
assist by Manu Sporny]
Gregg Kellogg: for example, .expand() has a callback... [scribe
assist by Manu Sporny]
Gregg Kellogg: We could use the JSONLD callback to report the
issue - the 'type' of the error, and a 'message', and based on
the class of the error - there is some other data. [scribe assist
by Manu Sporny]
Markus Lanthaler: Yes, but we should have the list. [scribe
assist by Manu Sporny]
Manu Sporny: Yes, we should - but the fundamental question here
is - do we have mode strict/lax mode? or do we have JSON-LD
processing events? I prefer JSON-LD processing events. [scribe
assist by Manu Sporny]
PROPOSAL: JSON-LD will support a JSON-LD Processor Event
mechanism that will report certain events (to be decided later)
via a callback given through JSON-LD API calls.
Gregg Kellogg: +1
Manu Sporny: +1 (In general)
Markus Lanthaler: +1 (in general as well)
Niklas Lindström: +1 (with details regarding error handling
filled in later on)
David I. Lehn: +0!
RESOLUTION: JSON-LD will support a JSON-LD Processor Event
mechanism that will report certain events (to be decided later)
via a callback given through JSON-LD API calls.
Manu Sporny: Discussion about whether or not we should re-use
'callback' in the JSON-LD API.
Markus Lanthaler:
http://www.w3.org/TR/websockets/#the-websocket-interface
Gregg Kellogg: In a perfect world - we might split these out
into different methods - maybe... but I don't write code like
that. The code paths become quite difficult in this case... you
end up having processing separated "spatially" throughout the
document. [scribe assist by Manu Sporny]
Manu Sporny: this often makes code more complex, as code is
scattered across the page. This argues for a single callback. You
don't want to overwhelm developers with options.
… this callback is called whenever a processing event happens.
If you don't want to stop with errors, always return true.
… with a JSON-LD processor, you tell it to do something, and
give it a callback which is used whenever there is some "event",
including the end of processing.
… if you need to break it out, the developer does that inline.
This give power to the developer.
Niklas Lindström: getting an event with type and message is an
easy way to start. If we see that adding multiple callbacks
reduces complexity, we can add later.
Manu Sporny: http://www.w3.org/TR/websockets/#event-definitions
Manu Sporny: the Event Definitions from web sockets looks like a
model we could follow.
… we could give options to developers on how they want these
to resolve.
… for example, we could allow them to handle datatype
transforms.
PROPOSAL: The JSON-LD Processor Event callback would be
registered for every JSON-LD API call, and would provide the type
of event and the data associated with the event for the callback.
This mechanism would be used to report potential errors, warnings
and when the processing of the document was complete.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0 (really need some implementations to valididate
all these ideas)
RESOLUTION: The JSON-LD Processor Event callback would be
registered for every JSON-LD API call, and would provide the type
of event and the data associated with the event for the callback.
This mechanism would be used to report potential errors, warnings
and when the processing of the document was complete.
Manu Sporny: we could let the developer decide how to detail how
to deal with bad data.
Gregg Kellogg: The corollary here is that whenever we say that
the processor should raise an exception - we call the callback.
[scribe assist by Manu Sporny]
PROPOSAL: When a JSON-LD processor processes input that would
result in an exception, it should instead call the JSON-LD
Processor Event callback with data concerning the issue that was
detected.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1 for browser implementations
David I. Lehn: +0
RESOLUTION: When a JSON-LD processor processes input that would
result in an exception, it should instead call the JSON-LD
Processor Event callback with data concerning the issue that was
detected.
Topic: ISSUE-116: Introduce @extension keyword?
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/116
Manu Sporny: Does anybody think we need to do this? [scribe
assist by Manu Sporny]
Markus Lanthaler: Not I. [scribe assist by Manu Sporny]
Gregg Kellogg: We would just ignore @extension now, so they
could do that... we'd just ignore it. [scribe assist by Manu
Sporny]
David I. Lehn: Validation is an interesting use case - we don't
do that now... [scribe assist by Manu Sporny]
David I. Lehn: It's important to think about how validation
could be integrated into JSON-LD. [scribe assist by Manu Sporny]
Markus Lanthaler: Well, it would be ignored. [scribe assist by
Manu Sporny]
David I. Lehn: we need to iterate on the JSON validator; it's
not "easy".
… If you had a generic extension mechanism, it would at least
allow people to experiment.
… there are probably better ways to do validation than we do
now; perhaps operating on triples.
David I. Lehn: I don't think our (Digital Bazaar's) JSON-LD
validator is easy... we need to iterate more before proposing
something. I dont' think we want to force any particular
validation mechanism on anyone. There is probably a better way to
do validation than the way we're doing - more Semantic Webby
operating on triples vs. the tree approach we're currently using.
[scribe assist by Manu Sporny]
Niklas Lindström: I've recently used SPARQL 1.1 and 'schemarama"
which helps.
Markus Lanthaler: are we not resolving this issue?
Manu Sporny: actually, yeah let's do that.
David I. Lehn: look at your clock :)
Markus Lanthaler: takes 2 minutes if we agree :-)
PROPOSAL: Do not support the @extension keyword at this point in
time.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1 but we should look at the use case for this and
figure out how to provide the needed hooks
Gregg Kellogg: +1
David I. Lehn: @extension may not be right, but we probably need
something for this
RESOLUTION: Do not support the @extension keyword at this point
in time.
David I. Lehn: hmm. i'm unsure about this. i think maybe the
@extension request is not even the right issue to be raising. it
would be better written as how to support such things as
validation and schemas
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Wednesday, 16 May 2012 02:52:21 UTC