Manu Sporny: Any updates/changes to the Agenda?

Gregg Kellogg: Publishing schedule

Manu Sporny: Ok.

Manu Sporny: Dave Lehn put together a logo for JSON-LD. http://json-ld.org/images/

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.

Manu Sporny: +1

Dave Longley: +1

Gregg Kellogg: +1

Françs Daoust: +1

Niklas Lindström:: +1

Markus Lanthaler: -0.5

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.

Niklas Lindström:: +1

Gregg Kellogg: +1

Manu Sporny: +1

Dave Longley: +1

Françs Daoust: +1

Markus Lanthaler: -0.5

David I. Lehn: +0

Gregg Kellogg: Note, this does not represent a change for @language.

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.

Gregg Kellogg: +1

Manu Sporny: +1

Dave Longley: +1

Françs Daoust: +1

David I. Lehn: +1

Markus Lanthaler: +1

Niklas Lindström:: +1

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.

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"

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.

Manu Sporny: +1

Dave Longley: +1

Markus Lanthaler: +1

Niklas Lindström:: +1

Gregg Kellogg: +1

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.

Gregg Kellogg: Thank's very much!