- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 26 Feb 2013 15:46:00 -0500
- 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-02-26/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-02-26
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Feb/0141.html
Topics:
1. JSON-LD Icons
2. Jeremy Carroll's request for @base
3. ISSUE-217: Disallow BNode identifier as Graph Name
4. ISSUE-218: Algorithm specification updates by editors
5. Publication Timeline
Resolutions:
1. Add @base to the JSON-LD syntax as an at-risk feature.
2. Support @base and @language declarations in the @context.
Warn developers that JSON-LD contexts that are to be used as
remote contexts probably shouldn't include @language or @base.
3. JSON-LD will continue to support blank node identifiers for
properties and graph names. When converting data to RDF 1.1, the
specification will not introduce any special checks to handle
these specific cases. It is up to the implementations to figure
out how to convert this data to something conformant to RDF 1.1.
4. Mark property generators as an at-risk feature in JSON-LD
1.0.
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, Gregg Kellogg, Niklas Lindström, Dave Longley,
François Daoust, Markus Lanthaler, David I. Lehn
Audio:
http://json-ld.org/minutes/2013-02-26/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Any updates/changes to the Agenda?
Gregg Kellogg: Publishing schedule
Manu Sporny: Ok.
Topic: JSON-LD Icons
Manu Sporny: Dave Lehn put together a logo for JSON-LD.
http://json-ld.org/images/
General approval from the group on the icons.
Topic: Jeremy Carroll's request for @base
http://lists.w3.org/Archives/Public/public-rdf-comments/2013Feb/0044.html
Manu Sporny: Adding in @base might need to be done before LC and
then marked as at-risk.
Niklas Lindström: What's the alternative?
Manu Sporny: You could create a term for the base IRI, and then
append that to the beginning of an IRI.
Niklas Lindström: I've always been pro @base, what you said is
not the same thing.
Gregg Kellogg: I agree - not having @base would require the
document to be re-written.
Dave Longley: I agree, easy feature to add.
Niklas Lindström: It was missing from Turtle for a long time,
and it was requested to add it.
PROPOSAL: Add @base to the JSON-LD syntax as an at-risk feature.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: -0.5
RESOLUTION: Add @base to the JSON-LD syntax as an at-risk
feature.
Gregg Kellogg: Is this limited to @context, or limited to the
body? Can you use it in an object.
Manu Sporny: Two ways we go about this - @base is not allowed in
the context and must be in the body - or @base should be in
@context only.
Niklas Lindström: I like @base in the body of the document, not
in the @context. Maybe @language in context is an argument for
@base in context.
Gregg Kellogg: Maybe we should disallow it from being used in a
remote context.
Gregg Kellogg: maybe we should add the same restriction for
@language used in a remote context.
Markus Lanthaler: The question is - do you trust the remote
context? If you don't, you shouldn't use it.
Niklas Lindström: That's true.
Niklas Lindström: We could say that you SHOULD NOT use @base or
@language in remote contexts.
Gregg Kellogg: Maybe an organization only publishes in a certain
language, so it makes sense to do so.
Manu Sporny: Couldn't you just override the language in your
document?
Dave Longley: It could be null for transient messages...
Niklas Lindström: Yes, you could set your @language and @base to
null in your local context.
Gregg Kellogg: if you set @base to null, you could just output
relative IRIs... it's not legal in and of itself, anyone that is
parsing the result can apply a base to it.
Manu Sporny: So, we're saying @language and @base can be used
both inside and outside the @context. You SHOULD NOT use it in
remote context,
Markus Lanthaler: normative statement about SHOULD NOT?
Gregg Kellogg: I don't see a good reason to have @base or
@language outside of @context. Putting it inside a local context
ties everything up in one nice area in the document.
Manu Sporny: Don't we support @language outside of @context now?
Dave Longley: Nope.
Manu Sporny: Ok, sound good.
PROPOSAL: Support @base and @language declarations in the
@context. Warn developers that JSON-LD contexts that are to be
used as remote contexts probably shouldn't include @language or
@base.
Niklas Lindström: +1
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Markus Lanthaler: -0.5
David I. Lehn: +0
RESOLUTION: Support @base and @language declarations in the
@context. Warn developers that JSON-LD contexts that are to be
used as remote contexts probably shouldn't include @language or
@base.
Gregg Kellogg: Note, this does not represent a change for
@language.
Topic: ISSUE-217: Disallow BNode identifier as Graph Name
https://github.com/json-ld/json-ld.org/issues/217
Manu Sporny: it seems to be clear that the RDF WG won't make any
change. Some people start to get annoyed [scribe assist by Markus
Lanthaler]
Markus Lanthaler: ... we might wanna propose to drop the feature
Markus Lanthaler: ... or we will keep it and say that such data
won't round-trip
Markus Lanthaler: ... the alternative proposal in the blog post
is so bad that we don't want to implement it. We think it will
damage RDF in the long term
Markus Lanthaler: ... our preference would be to keep support for
bnodes in predicates and graph labels
Markus Lanthaler: ... we shouldn't throw an error when converting
to RDF
Niklas Lindström: I am in agreement with you - as long as the
language is explicit about this not working for compliant RDF
systems, we support it syntactically, stay silent on it in
spirit. People that need it can use it, but we can't guarantee it
will work w/ legacy RDF systems. If you use the feature you'll be
violating RDF 1.1 Concepts.
Niklas Lindström: I think it was good to air these things in the
discussion. I sympathize with the problems. I think Pat Hayes
insight was very enlightening. It was also frustrating to read.
Yes, with appropriate notes, I wouldn't be against this.
Niklas Lindström: There are systems that already support bnodes
for graph names in the wild - rdflib already does. They will
probably add an RDF 1.1 compliance level, but you can work around
it and parse RDF datasets into rdflib. I understand the
limitations on storage. The graph names are usually used in that
aspect. I also understand why RDF 1.1 doesn't support it.
Gregg Kellogg: The only concern is that the algorithm (node map
algorithm and convert to RDF algorithm are written wrt to the
abstract syntax). So, they're aligned w/ concepts... but we say
we're composing a triple with a blank node as predicate? In
convert to RDF algorithm we're converting to RDF using an
algorithm for blank node as graph name.
Gregg Kellogg: Maybe we can change it into a note for the narrow
purpose of this algorithm... we can extend for blank node
identifiers in this case. Hopefully it won't raise any hackles in
the WG.
Markus Lanthaler: The cleanest solution would be to just drop it
in the RDF conversion algorithms. We say clearly in the syntax
spec stating that those features won't round-trip to RDF.
Markus Lanthaler: RDF conversion isn't an API call - just a
description on how to convert to RDF.
Gregg Kellogg: If we do that, we disallow the Digital Bazaar use
case.
Manu Sporny: Yes, that's a problem.
Markus Lanthaler: Does NQuads support blank nodes for graph
names?
Manu Sporny: No, but it's also not a REC.
Gregg Kellogg: Yeah, there is no "official" NQuads spec.
Gregg Kellogg: if you look at N3, it does specifically allow for
bnodes in graph names and property locations.
Niklas Lindström: Yes, it does.
Gregg Kellogg: They manage to do that anyway, even though it
does extend the data model.
Niklas Lindström: Yes, I even went so far to leverage blank node
properties and it became complex very quickly.
Manu Sporny: Yes, there are issues with blank nodes as
predicates, makes things algorithmically very complex.
Gregg Kellogg: If you do this, you no longer depend on
facilities for RDF... you're not really using RDF.
Markus Lanthaler: i was thinking of changing the rdf bit just so
it's clearly different. probably wouldn't want to use n3's
version directly either in that case. open to suggestions for
changes or anyone can fiddle with the svg. [scribe assist by
David I. Lehn]
Markus Lanthaler: Can we say nothing in the spec?
Dave Longley: Could we say that it's an optional feature, to
preserve this sort of thing?
Markus Lanthaler: Could we say the behavior is not specified in
the specification. We don't check for it. It's up to the
implementer to decide.
Dave Longley: Yes, I agree.
Gregg Kellogg: Agreed.
PROPOSAL: JSON-LD will continue to support blank node identifiers
for properties and graph names. When converting data to RDF 1.1,
the specification will not introduce any special checks to handle
these specific cases. It is up to the implementations to figure
out how to convert this data to something conformant to RDF 1.1.
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
David I. Lehn: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: JSON-LD will continue to support blank node
identifiers for properties and graph names. When converting data
to RDF 1.1, the specification will not introduce any special
checks to handle these specific cases. It is up to the
implementations to figure out how to convert this data to
something conformant to RDF 1.1.
Topic: ISSUE-218: Algorithm specification updates by editors
https://github.com/json-ld/json-ld.org/issues/218
Manu Sporny: Starting at section 5.5
Markus Lanthaler: Step 3.2 - it's not needed, but I can't
remember why.
Dave Longley: Handling keyword aliasing for @graph - maybe for
dropping free-floating nodes or some other check?
Dave Longley: yeah, older spec text was checking the active
property against @graph, but that didn't take into consideration
aliases for @graph. The new spec text ensures that it's expanded.
Markus Lanthaler: Expanded active properties wouldn't be needed?
Dave Longley: You can't check the active property against @graph
because it could have been aliased.
Markus Lanthaler: You don't need to handle @graph here, right?
Markus Lanthaler: under the steps 8.4, validation is done there,
but the keywords aren't handled there. You're not doing
processing, you're just doing validation. While expanding the
value of @graph or @id, instead of doing that in value expansion,
the values would be simplified.
Dave Longley: So, value expansion would be simplified?
Markus Lanthaler: The question is whether we want to split that
validation part under 8.4 and the actual processing.
Dave Longley: So you want to combine the validation and
processing steps?
Markus Lanthaler: Yes, under 8.4 you check every keyword, but
you don't do anything with it... then you actually do something
with it in 8.7, 8.8, and 8.9
Dave Longley: if you handle the list at the same place that you
do the validation, you have to duplicate the code that you have
to recurse through an array.
Dave Longley: If you do the validation first and then the
processing, you can have common code to do the recursion. If you
don't do it that way, you can't share the recursive processing
code.
Manu Sporny: let's move this to the mailing list discussion.
Markus Lanthaler: Step 3.4.2: ... or a bnode ID - we never
validate IRIs, but we don't validate whether it's a valid IRI.
Dave Longley: we need to do some kind of check to make sure
something that has a colon or a keyword - we don't have a term
for that, we should use that term throughout the specification.
Manu Sporny: RDFa does it by CURIEorAbsoluteIRI - maybe we can
do something similar.
Markus Lanthaler: Maybe KeywordOrIRIOrBlankNode ?
Dave Longley: It's like a JSON-LD Expanded Key?
Markus Lanthaler: If expanded property is either null or is: not
an array, an absolute IRI or a keyword, then drop key by
continuing to the next key.
Dave Longley: So we say it must be a "valid ExpandedKey" and
then we link to a place in the spec that states what "valid"
means.
Dave Longley: It's any keyword except for @context - you could
be expanding an alias.
Gregg Kellogg: In the context of a node, it can't be @value or
@list?
Dave Longley: it's not just in a node -it might be in a literal.
We want to use the same word there.
Markus Lanthaler: "ValidProperty" ?
Manu Sporny: Why don't we bikeshed the name later, and structure
the spec correctly now?
Niklas Lindström: +1 for expanded key
Gregg Kellogg: For right now "ExpandedKey" - we can change it
later.
Niklas Lindström: .. ExpandedKeyRightNow ;)
Markus Lanthaler: Steps 3.4.3.x: is basically the validation
stuff we talked about before...
Markus Lanthaler: Step 3.4.4.2: "and value language value in
value" is confusing
Dave Longley: Yeah, that's really confusing, we need to do
something else.
Markus Lanthaler: Maybe format variables in typeset courier.
Manu Sporny: We usually do "<em>"
Dave Longley: Maybe we should also colorize it?
Markus Lanthaler: Yeah...
Markus Lanthaler: language value changes to languageValue ?
Manu Sporny: Maybe we just do class="variable" around the
variable?
Markus Lanthaler: Camel case the variables?
Gregg Kellogg: let's stay away from the religious debates about
camel case...
Manu Sporny: I think if we mark it up in italic purple, we don't
also need to camel case.
Markus Lanthaler: ok.
Markus Lanthaler: Step 3.4.6: might need some clarification. It
might be easier to put it under 3.4.3 - this is now section 8.7 -
3 lines of handling @list and @set - maybe we want to separate
this into a substep?
Dave Longley: Yeah, maybe we just want to break this into a
couple of sub-steps.
Markus Lanthaler: Can we break it up?
Dave Longley: yes, looks possible - let's do it.
Dave Longley: it'll just be 3 steps, it'll look a lot better.
Markus Lanthaler: 8.12 we handle keywords separately... if xyz,
then set the key to something. I think it might be simpler to do
this elsewhere, but let's discuss on the mailing list.
Dave Longley: I think we'll just have to move this around and
see if it looks better, if so, keep it, if not, don't.
Markus Lanthaler: Last point - insideList flag - do we need that
flag? Would it be enough for current active property is @list or
coerced to a list, instead of passing that flag around.
Dave Longley: When I was working on this, I had a test case for
this - once we get the API errors in the spec, I'll be able to
check this one. If we can remove it, we should remove it,
otherwise we should have a test that says why we need this flag.
Dave Longley: I got all of the error phrases back in the spec
last night. We have a phrase for the type of error now, I need
Gregg and Markus to go in and figure out what needs to change to
accomodate both of them. I tweaked some of the error lists,
consolidated some, added some. Needs review.
Gregg Kellogg: I think the changes are good, mostly what I was
going for.
Gregg Kellogg: maybe we should link to the error code section?
Dave Longley: Should they become trefs?
Gregg Kellogg: I like that they're styled differently, maybe
done not as a tref, but a dtref?
Markus Lanthaler: Currently code w/ a special error class - we
could pre-process in ReSpec.
Discussion about how to make this work in ReSpec.
Markus Lanthaler: Gregg, you want the error in the algorithm to
link down to the entry in the error table, right?
Gregg Kellogg: Yes.
Manu Sporny: Looks like 5.10 is the next thing that needs to be
discussed.
Dave Longley: Talking about compactArrays as an option is tying
it to the API instead of the algorithm - I don't know if we want
to handle this w/ another flag.
Gregg Kellogg: I think what I was trying to say before - "if
compacting arrays" vs. specifically talking about flags... flags
are in there, I don't think they're going away. Options are less
API-ish than flag.
Dave Longley: What would your preference be for the language?
Dave Longley: "If a choice has been made to compact arrays"?
Gregg Kellogg: It was basically a feeling about being tied so
closely to the API. Important take-away is to consider that when
looking at algorithmic text, and you're doing that now.
Dave Longley: I'll try to come up with something that is more
prose-y
Gregg Kellogg: great.
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/218#issuecomment-14118336
Markus Lanthaler: The link above is a proposal about how to
re-order the algorithms.
Dave Longley: Maybe we want to put context processing under it's
own group entirely. Maybe they need their own grouping.
Markus Lanthaler: Like "IRI Processing", for example?
Gregg Kellogg: It depends - these seem like they're tightly
bound - when expanding IRI, I'm doing it relative to the context.
Dave Longley: My only issue with that is that you could say this
about every one of these algorithms. It seems somewhat arbitrary
where you draw the line. It seems like some of these are
subalgorithms, you don't call them on their own - maybe something
like "IRI Processing" as Markus suggested, might be best.
Markus Lanthaler: Should we introduce a new group like "IRI
Processing"?
Dave Longley: We can call it that for now.
Gregg Kellogg: They could also be bound together with various
"Compaction/Expansion" algorithms?
Dave Longley: That's fine with me. I think Markus wanted to move
it up because it's a concept that is used generally...
Markus Lanthaler: IRI Expansion is so title bound to context
processing, it doesn't make much sense to put it elsewhere.
Dave Longley: Maybe "Utility sub-algorithms"
Topic: Publication Timeline
Manu Sporny: We handed the JSON-LD 1.0 Final Community Group
Specification over to RDF WG - we need some changes before it
goes to LC - add at-risk for property generators, @base, clarify
blank nodes as predicates/graph names.
Gregg Kellogg: We may want to drop property generators entirely?
Manu Sporny: I don't know about taking out entirely - we need
feedback from Lin and Stephane.
Niklas Lindström: Compared to @rev, property generators are
really complex and we only put it in for Drupal.
Dave Longley: It also polluted the expansion algorithm. The
feature on it's own is complicated and it made all the other
algorithms more complicated.
PROPOSAL: Mark property generators as an at-risk feature in
JSON-LD 1.0
Manu Sporny: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
RESOLUTION: Mark property generators as an at-risk feature in
JSON-LD 1.0.
Manu Sporny: Do we want a super-session to go through the rest
of the API spec?
Markus Lanthaler: I'd be fine either way.
Manu Sporny: I don't think meeting before next Tuesday is
necessary.
Markus Lanthaler: I think the JSON-LD Algorithm spec is very
close, algorithms seem pretty solid.
Manu Sporny: End of the call, anything else?
Niklas Lindström: Yeah, JSON-LD is being used very heavily at
National Library of Sweden - we're ahead of Library of Congress
in that respect!
Niklas Lindström: What we do now is we have our JSON shapes in
place, and we have two contexts we use for book-keeping - we can
mutate the RDF at will depending on which vocabulary is willing.
Gregg Kellogg: The BBC is giving a talk at SemTech on their use
of JSON-LD in their Linked Data program.
Manu Sporny: Go Sweden!
David I. Lehn: we should have a page on the website linking to
these sites and projects using json-ld
Gregg Kellogg: We do this at Wikia now - JSON-LD is working
nicely for us.
Happy Birthday (tomorrow) to Gregg ! Well wishes all around for him.
Gregg Kellogg: Thank's very much!
-- 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, 26 February 2013 20:46:33 UTC