Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/28

Gregg Kellogg: most people will want to use existing tools and don't need all the processing details

Dave Longley: i think it's a good idea to move the complexity of the algorithms for the APIs to another document.

Gregg Kellogg: danger in separating spec. can diverge. people might not see both.

Dave Longley: a good point, but i think we can mitigate that a bit by splitting according to a "separation of concerns" like Markus said.

Niklas Lindström: agree. framing orthogonal to syntax. in favor of split.

Dave Longley: another point is that we can explain certain parts of how JSON-LD works

Dave Longley: compaction, expansion, etc.

Dave Longley: in the syntax document.

Dave Longley: and the actual algorithms to work with those ideas can be written however people want ... the API/algorithm document only explains one way

Niklas Lindström: keep spec together for now with sections for various parts until we need to split into separate documents.

Gregg Kellogg: +1

Ted Thibodeau Jr.: +1

Niklas Lindström: +1

David I. Lehn: +1

Dave Longley: +1

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/27

Ted Thibodeau Jr.: voip-ld, 3428 is terraces

Gregg Kellogg: normalization is sufficiently general that it should be taken out of spec.

Dave Longley: my understanding is that we could keep the normalization API

Dave Longley: for JSON-LD but move the algorithm to another document

Dave Longley: since normalization might have multiple algorithmsi n the future anyway.

Dave Longley: there should be a way to normalize JSON-LD ...

Dave Longley: especially if we want to have a way to say there is "one way" to represent a particular graph

Dave Longley: helps with comparing graphs.

Dave Longley: i think both myself and manu would be ok with moving the algorithm itself into a generalized document

Dave Longley: but keeping normalize() as an API call.

Thomas Steiner: +1

Dave Longley: +1

Gregg Kellogg: +1

Thomas Steiner: you might try [email protected]? it's supposed to work either way.

Niklas Lindström: +0 (no opinion)

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/26

Gregg Kellogg: having seen strong opposition to moving normalization out

Niklas Lindström: http://lists.w3.org/Archives/Public/public-linked-json/2011Sep/0068.html

Gregg Kellogg: want a single way to provide functionality

Niklas Lindström: not sure of exact way @vocab and @base work in JSON-LD, think it's similar to RDFa and Turtle, and they have different uses

Ted Thibodeau Jr.: tomayac - try sip:[email protected] including the "sip:" prefix

Niklas Lindström: in other languages, base works with URI resolution. [discussing base vs vocab]

Thomas Steiner: sorry, might be firewall issues blocking SIP on your end?

Dave Longley: maybe just make the difference and necessity more clear in the spec?

Gregg Kellogg: base used as aritmatic adding paths, vocab more

Niklas Lindström: issue mentions base not used for relative URIs. maybe a spec bug.

Gregg Kellogg: +1

Ted Thibodeau Jr.: +1

Niklas Lindström: +1

Gregg Kellogg: yes, should be in spec if not.

Dave Longley: +1 (but make clearer in spec necessity and difference)

Niklas Lindström: .. clarification: base not used for resolving subjects

Niklas Lindström: (only objects)

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/8

Dave Longley: this has to do with adding options to the compact API so that IRIs are automatically coerced

Gregg Kellogg: [discusses issue text]

Dave Longley: i think it's mostly an API change ...

Dave Longley: the only "syntax" change would be if we created a new name for this form

Dave Longley: i think this should be about options to the compact call.

Dave Longley: that may or may not be the default options.

Dave Longley: -1 to regex on IRIs ... it has been suggested before when talking about various Linked Data formats and there seems to be too much ambiguity

Gregg Kellogg: suggestion to use regex to recognize IRIs. wouldn't need @iri keyword. problem if you wanted literal IRI would need to mark it up as such.

Niklas Lindström: sounds like options to have 'native' JSON form

Dave Longley: for ease of use.

Gregg Kellogg: eliminate keywords outside of context. avoid longer forms.

Niklas Lindström: worth investigating. some amount of magic coercion might be good for IRIs as well as dates.

Gregg Kellogg: date/time forms might make sense for direct conversion.

Dave Longley: i think regex and magic stuff should be discussed a bit more on the mailing list

Niklas Lindström: date and time alone might be good for many use cases. would be prudent to have explict coerce rules.

Gregg Kellogg: don't want too many options in processing. suggest to adopt standard way for conformant processors to behave without additional options.

Niklas Lindström: if magic coercion enabled by default might lead to trouble in some cases.

Gregg Kellogg: need to be able to fall back to keyword mechanisms.

Gregg Kellogg: -0

Dave Longley: +1

Gregg Kellogg: suggest to defer and discuss on mailing list

David I. Lehn: -1 (i guess i have some comments too)

Dave Longley: premature

Dave Longley: -1

Niklas Lindström: vote yes, but want to control in the context. +1 with controls.

David I. Lehn: we started with such microsyntaxes, such as using <>, but that created more problems. [scribe assist by Gregg Kellogg]

Gregg Kellogg: ... This may get to similar problems we found before, but we do have an @iri escape route.

Gregg Kellogg: ... Magic behavior may be hard to understand.

Niklas Lindström: "@coerce": { "@iri": "@magic" }

Dave Longley: things get hairy when we go "above and beyond" what syntax JSON itself supports.

Niklas Lindström: seen data with IRIs that should be plain strings. never seen data with datetime string that wasn't intended to be a datetime

Dave Longley: this was a mess with microsyntaxes ... and adding "magic" is going to be very similar to this and difficult to get right.

Dave Longley: having the compact API do this for people ...

Dave Longley: is an option.

Gregg Kellogg: needs more discussion and may come to same conclusion as before that it's more trouble than it's worth

Dave Longley: more options that gregg doesn't like

Dave Longley: well, coerce already will make anything a "string"

Dave Longley: but, yes, we could use something like @datetime

Niklas Lindström: wondering value of top level language directive

Gregg Kellogg: not yet discussed. considered something similar with context block of string literals. either want to set language for entire document or fine detail of different languages for each property. similar to lang property for literals we have now.

Niklas Lindström: anywhere as in XML may be too much. top level may be good. or use in coercion.