JSON-LD Community Group Telecon

Minutes for 2012-07-17

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0022.html
Topics
  1. JSON-LD for Biomedical Informatics
  2. JSON-LD First Public Working Drafts
  3. ISSUE-132: Reconsider prefix/suffix separator
  4. Super sessions
Resolutions
  1. Do not change the prefix-suffix separator from COLON ':' to anything else.
Chair
Manu Sporny
Scribe
Gregg Kellogg
Present
Manu Sporny, Gregg Kellogg, Niklas Lindström, David I. Lehn, Markus Lanthaler, François Daoust
Audio Log
audio.ogg
Manu Sporny is scribing.
Manu Sporny: Standard agenda... anything else to add to this?
Gregg Kellogg: I did a talk on JSON-LD to the bioinformatics group - also the Protoge group.

Topic: JSON-LD for Biomedical Informatics

Gregg Kellogg: lots of ontology work there - work around Protoge - some work mapping multiple ontologies together.
Gregg Kellogg: Lots to do with different format differences - as the applications make a lot of use of Web pages - JSON-LD would be used to support REST-ful APIs in HTML-based user interfaces.
Manu Sporny: Were there any feature requests?
Gregg Kellogg: The main one that keeps coming up is @id mapping... something being in a different form than is stated.
Manu Sporny: so @id mapping via @graph?
Gregg Kellogg: no, template-based IRI generation.
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/108
Niklas Lindström: We should be able to do something simple.
Manu Sporny: I'm confused why they can't just generate the @id from their data?
Gregg Kellogg: Yeah, I mentioned that.
Niklas Lindström: This is a teaching issue, potentially - we should consider this if we go down this path. People tend to conflate what we mean by "@id" with what they use internally as an id... We mean "@id" to connect data with other stuff - it's a public identifier. They seem to be using @id like a local identifier.
Niklas Lindström: It's dangerous to conflate these things - you don't link by IRI anymore. There are things here that we need to be explicit about.
Gregg Kellogg: http://tools.ietf.org/html/rfc6570
Gregg Kellogg: We may want to look at URI templates - incorporate that.
Niklas Lindström: http://code.google.com/p/court/wiki/COIN
Niklas Lindström: I have a temporarily shelved project called COIN (above)
Niklas Lindström: This covers how to create IRIs from parts of the data... I use that in the legal information project I worked on. We had very strange legacy forms and needed to generate @ids.
Niklas Lindström: I started to declare these definitions in raw JSON - needed to define a vocabulary to make this more clean.
Niklas Lindström: I started to write a spec for it. Richard Cyganiak thought that it would be a good thing to have.
Niklas Lindström: It's not always as simple as picking the one key from the data - it's often a combination of keys.
Niklas Lindström: Very much depends on the old ways of publishing the data.
Manu Sporny: I'm concerned about re-opening this issue, it's fairly easy to generate these @ids in code.
Niklas Lindström: Different IRIs represent different things - there's a decent bit of complexity here.
Gregg Kellogg: The other area that came up is the use of URNs as an identifier space - the lack of a @base keyword prevent us from creating URNs automatically.
Gregg Kellogg: There was some discussion about whether @base should be something we should add back into JSON-LD.
Niklas Lindström: Yes, that or some other prefix... you could define terms for the @id itself... bind the key to the proper IRI and use that opaque value for the value of the @id property. If you really want that shape, you can push all the @ids into the context.
Gregg Kellogg: I will update the issue to the minutes from today.

Topic: JSON-LD First Public Working Drafts

Gregg Kellogg is scribing.
Manu Sporny: JSON-LD FPWD out!
… When we started JSON-LD in the CG, we were unsure where it was going. However, it's been going smoothly in the RDF WG and the chairs support getting this out as a REC.
Markus Lanthaler: http://www.w3.org/TR/json-ld-syntax/
Markus Lanthaler: http://www.w3.org/TR/json-ld-api/
… I forgot to include niklas' name in the FPWD, but I'm trying to get it updated.
Manu Sporny: During the RDF call last week, there is concern about how we're accepting changes into the spec.
… The API and Syntax are now under the purview of the RDF WG, so the CG isn't working on them any more.
… That means we can't accept pull requests from people not in the WG.
… If you have commit rights, make sure their from someone who's an RDF WG member.
… This relates to ensuring that their IPR is licensed to be used in the spec.
… Alternatively, with WG members can make updates using their own language.
… This means that dlongley and taaz can't make changes as they're not WG members.
Niklas Lindström: I've been waiting for response to get in the WG myself.
Manu Sporny: If something does need to go in, it requires an explicit license.
Manu Sporny: Change requests can go into RDF Comments. Thus, if a pull request comes in, we can ask them to send it to RDF Comments.
… There are some open questions of if a pull request can basically assert the license, but it's not worth persuing right now.
… Also, don't accept patches sent into RDF Comments.
Niklas Lindström: It's unfortunate that dave & dave can't contribute. Sort of like my situation, but worse.
… As it is right now, I take time off to do stuff, and I can't motivate my company to pay for that.
David I. Lehn: just to understand, how much can we even participate on these calls? is suggesting changes here a problem?
Manu Sporny: No, suggesting changes here is not a problem... but we do need to clear up the legalities.
David I. Lehn: It's one issue for us, but for random people that come across the specs, it's another issue.
Gregg Kellogg: The intention is to deal with substantive changes - not typos. [scribe assist by Manu Sporny]
Manu Sporny: it's an issue of keeping things on record at W3C.
… This means we need to be careful when new people join the call. However, there's no "thought police", but when something new comes up, we need to be careful.
… I'm discussing with Ian at W3C.

Topic: ISSUE-132: Reconsider prefix/suffix separator

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/132
Markus Lanthaler: basically, reconsider the use of ":" as a separator in a Compact IRI, or use another character to allow it to be used as an identifier within a programming language.
… People don't like to use prefixes, because they can't use the "." notation.
… If we're going to change it, we should do it now.
Manu Sporny: agree that using "." operator is preferred.
… What we did with Payswarm was to decide to turn everything into a term.
Manu Sporny: Instead of this - sec:publicKey we now do this: publicKey
David I. Lehn: and our context has become large!
Manu Sporny: this has made for large contexts.
… "_" and "__" are problematic; sometimes used in vocabularies.
… "$" is used in JavaScript, but is confusing when you look at the code.
… @vocab is an issue when using multiple vocabularies.
… Using the [] operators is slightly annoying, but not too bad.
Niklas Lindström: I generally agree that we should use terms in the context to handle these issues.
… I had thoughts of using prefix with another keyword, and I've come to see that if I'm not defining the term in the context, I'm probably trying to mix too much.
François Daoust: [I think using terms, either explicitly or through @vocab, really helps, so I wouldn't try to change a prefix that is already agreed upon pretty much everywhere else]
… A context is not a general thing, but is a very specific thing. If I want to publish everything I've got, the explicit use of @prefix or IRIs is appropriate.
… The explicit needs to use [] is a way to signal that it is auxiliary data, and not intended to be primary.
… in general, using terms to define the context is the way to go.
… I think that CURIEs are a pragmatic tool to make IRIs compact, but that's just for data packing.
… That said, it applies regardless of if you use ":" or something else.
… If the issue crops up at general intervals, I wouldn't mind a mechanism of defining an alias for ":" in the context, but I'd rather not switch to it.
Gregg Kellogg: I'm working quite a bit with my own vocab, using schema.org - when I use schema terms, there are quite a number of them. Programmatically, writing code to access elements from objects, I know what I want to access... so I alias "@id" and "@type" in backbone. [scribe assist by Manu Sporny]
Gregg Kellogg: There are certain things I expect every object to have, such as a name or description - when accessing range, subtypeof - for those cases, I define terms to make it easy. It's for the cases where my logic is not built to access things that are not known in there, I couldn't use dot-notation. My logic doesn't try to deal with that data. [scribe assist by Manu Sporny]
Gregg Kellogg: I don't see a need to be more explicit to allow dot notation for things that are not already built into my code. [scribe assist by Manu Sporny]
Manu Sporny: the other issue with "$" is that can be confused with jQuery if you're scanning through the code.
Markus Lanthaler: I agree with the arguments, but it's more about why people are using @vocab; it's not that it's missing, but because prefixes loose some convenience. On the other hand, people don't want large contexts.
Niklas Lindström: I don't see how this makes the need for @vocab to go away. WIth @vocab, you use the terms from the vocabulary "as-is".
Markus Lanthaler: using as-is, means that you don't need to use brackets.
w+
Manu Sporny: I think that for some sub-set of users, the use of @vocab is useful. It's mainly useful for vocabularies such as schema.org.
… I know some of the people from Google like this because it makes the data look clean.
… I don't know if we can make an argument about the primary reason people are using these attributes. For example, If we changed it to "_", our company still wouldn't use it.
… We think our developers are going to want to use "." notation. Developers would rather use ".asset" rather than ".ps_asset".
… We've really switched our opinions on CURIEs in general. They're great for compacting use of IRIs, but when you actually go to work with the data, terms are much more useful.
Gregg Kellogg: I do have some other uses where I use terms - an annotation property - what term I want to use in the OWL definitions - the reason for that is not because of programmatic access - it's what users expect for common properties. I use OWL with restrictions as a way to show properties that are expected to be expressed in an object. For those types of things, I want to make it friendly... [scribe assist by Manu Sporny]
Manu Sporny: ...to developers that use 'name' or 'date' without having to do things like 'schema_name' or 'schema_date'.
Gregg Kellogg: That's really where terms come in handy - with regards to that, I don't find having to use square brackets to be problematic. [scribe assist by Manu Sporny]
PROPOSAL: Do not change the prefix-suffix separator from COLON to anything else.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0.5
David I. Lehn: +1
RESOLUTION: Do not change the prefix-suffix separator from COLON ':' to anything else.
François Daoust: +1
Niklas Lindström: Should we introduce an alias for ':' ? [scribe assist by Manu Sporny]
PROPOSAL: Allow the prefix-suffix separator to be aliased (for example, '$' in addition to '
Manu Sporny: -1
Markus Lanthaler: -1
Gregg Kellogg: -1
Niklas Lindström: +0.5
David I. Lehn: +0
François Daoust: +0
Group consensus on not allowing prefix-suffix separator aliasing.

Topic: Super sessions

Manu Sporny: preference for 75 min or 90 min calls.
Niklas Lindström: better than 120!
Manu Sporny: next call will be 90 minutes
… we'll continue on 90 minute calls while we get through to LC.
François Daoust: [regrets for next 2 weeks]