JSON for Linking Data Telecon

Minutes for 2011-9-10

Gregg Kellogg
David I. Lehn
Gregg Kellogg, David I. Lehn, Dave Longley, Niklas Lindström, Ted Thibodeau Jr., Thomas Steiner
Audio Log
David I. Lehn is scribing.

Topic: ISSUE-28: Markus' spec-split proposal

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
... might help for wider adoption of spec
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
(sorry, missed last speaker. who was that? had some volume issues here)
Niklas Lindström: keep spec together for now with sections for various parts until we need to split into separate documents.
PROPOSAL: 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
RESOLUTION: Keep spec together for now with sections for various parts until we need to split into separate documents.

Topic: ISSUE-27: Normalization in an external document

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.
PROPOSAL: Move normalization to a separate spec.
Thomas Steiner: +1
Dave Longley: +1
Gregg Kellogg: +1
Thomas Steiner: you might try json-ld@voip.digitalbazaar.com? it's supposed to work either way.
Niklas Lindström: +0 (no opinion)
RESOLUTION: Move normalization to a separate spec.

Topic: ISSUE-26: Merging @base and @vocab

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/26
Gregg Kellogg: having seen strong opposition to moving normalization out
... concern is having two mechanisms that do same thing and it is confusing
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:json-ld@digitalbazaar.com including the "sip:" prefix
... common to use same domain for subjects as having common vocab
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
... keep base and vocab. in turtle fall back on default prefix. not as desirable in JSON-LD due to need for ':'. use of vocab allows bare names.
PROPOSAL: Keep @base and @vocab as separate concepts within JSON-LD
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)
RESOLUTION: Keep @base and @vocab as separate concepts within JSON-LD
Niklas Lindström: .. clarification: base not used for resolving subjects
Niklas Lindström: (only objects)

Topic: ISSUE-8: Optimizing Compact form

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
... options to have no JSON-LD concepts in output
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.
i think this needs to be discussed more on the mailing list
PROPOSAL: Add an option to the compact API to automatically type coerce IRIs.
Gregg Kellogg: -0
Dave Longley: +1
i think this needs to be worked out some more
... maybe someone needs to try it and see how well it works
... maybe it's too hard or results are a mess
Gregg Kellogg: suggest to defer and discuss on mailing list
PROPOSAL: Use regexp to recognize IRIs and avoid use of @iri
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.
... problematic without controllable options
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
... might adopt keywords for more datatypes without using xsd types
Dave Longley: well, coerce already will make anything a "string"
... typically have datetime as value without having to import datetime xsd space into spec
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.