JSON-LD Telecon Minutes for 2012-07-17

Thanks to Gregg for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-07-17/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
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:
   http://json-ld.org/minutes/2012-07-17/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.
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
François Daoust: +1

RESOLUTION: Do not change the prefix-suffix separator from COLON
   ':' to anything else.

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]

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 17 July 2012 17:31:02 UTC