W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2013

JSON-LD Telecon Minutes for 2013-03-05

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 05 Mar 2013 12:26:29 -0500
Message-ID: <51362AC5.8070702@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Gregg for scribing! The minutes from today's telecon are now
available.

http://json-ld.org/minutes/2013-03-05/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-05

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0006.html
Topics:
   1. ISSUE-218: Algorithm specification updates by editors
   2. JSON-LD Property Generators
   3. ISSUE-221: Inverse properties in JSON-LD
   4. ISSUE-223: JsonLdOptions base vs. @base
   5. JSON-LD latest API issues
Resolutions:
   1. Remove Property Generators from JSON-LD before Last Call
      due to no developers needing the feature, the feature having a
      high potential of misuse, and because of the complexity it adds
      to the specification.
   2. Put JSON-LD Inverse Properties into the JSON-LD 1.0
      specification as an at-risk feature.
   3. 'base' (passed in via the API) sets the document base,
      @base (in the document) overrides any value set by 'base' (passed
      in via the API).
   4. Allow @base to be set to the empty string. If @base is set
      to the empty string, relative IRIs are processed according to RFC
      3986 Section 5.2.2 (which is how they're always processed in
      JSON-LD).
Action Items:
   1. Gregg to look at adding support in ReSpec for auto-quoting
      variable names in algorithms.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Gregg Kellogg, Manu Sporny, Markus Lanthaler, Dave Longley,
   Niklas Lindström, Paul Kuykendall, Lin Clark
Audio:
   http://json-ld.org/minutes/2013-03-05/audio.ogg

Gregg Kellogg is scribing.

Topic: ISSUE-218: Algorithm specification updates by editors

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218
Manu Sporny: Let's pick up at 5.10 Compaction Algorithm
Markus Lanthaler:  should we use call time for this?
Manu Sporny:  history shows that if we don't, it doesn't happen
   offline
Manu Sporny:  most things are checked, we should be able to get
   through it in 30 minutes
Markus Lanthaler:  the comment was if we need to describe how a
   shallow copy is made, as there is a lot of detail.
   … Since properties can be added or deleteted, that shouldn't
   happen.
   … Do we need to explain in such detail? Or, just say "create a
   shallow copy".
Dave Longley:  people might implement it incorrectly. You can't
   just copy the properties and reference the array; it's actually
   two-level.
Manu Sporny:  I think that's too vague. A "two-level shallow
   copy" raises more questions.
Gregg Kellogg:  Perhaps we can say do a "two-level shallow copy"?
   [scribe assist by Manu Sporny]
Markus Lanthaler:  I think most languages would also copy arrays
Dave Longley:  I think just PHP does this, most other languages
   don't. Just the keys would be copied, and the arrays referenced.
Manu Sporny: 5.12 Inverse Context Creation Subalgorithm
Markus Lanthaler:  similar point; in some steps it is also overly
   explicit in how to do things.
   … As described, I wouldn't understand that it should be a
   pointer; we should be a bit more explicit that we mean a pointer.
   … In this case, it's not a shallow copy.
Dave Longley:  this happens a couple of places in the spec where
   we want to create a temporary variable. We also have the issue
   where gkellogg would like the algorithms to be described more
   "mathemetically".
   … Not sure what language we should use. We might say "set to a
   reference of a member".
Markus Lanthaler:  it would be enough to say "set variable to a
   reference of the value of key".
Dave Longley:  we could say "reference the value of the key in
   the map", or "let this variable identify the value of the key in
   the map"
Manu Sporny:  prefer the first form.
Dave Longley: "reference the value of the key in the map using
   the variable foo"
Markus Lanthaler:  makes sense.
Markus Lanthaler: +1
Manu Sporny: Next up is step 3.3.6
Markus Lanthaler:  this is purely editorial. Checks are all
   negative, it would be easier to be positive ("if there is a type
   mapping, rather than if there is not a type mapping")
Now on 5.11 IRI Compaction Algorithm
Manu Sporny: suggest dropping the “parent” parameter...
Manu Sporny:  about dropping the parent parameter here, and in
   5.13
Dave Longley:  this exists so that you don't remove things.
Markus Lanthaler:  the question is if you remove the duplicates
   in term selection or inside the compaction algorithm itself.
   … Currently it's done in term selection, which also modifies
   data. I think it's cleaner to make term selection and IRI
   compaction to just return information, and leave modification to
   the compaction algorithm.
   … The first one where all duplicates are found is picked, and
   duplicates are removed.
Dave Longley:  my implementation doesn't remove data in term
   selection.
   ... There is a flag for removing things, which is set to false
   when called from term selection.
   … The actual removal happens during compaction.
Markus Lanthaler:  this means it loops over sub-trees twice.
   … My selection is to not pass any data, but just return
   candidates.
   … The final selection is done in compaction.
   … If there are property generators, you get back potential
   property generators and a fallback term.
Dave Longley:  this is less algorithmically correct, but seems
   odd that term-selection doesn't actually select a term.
Manu Sporny:  it seems to me that term selection should give a
   single term.
Dave Longley:  if you pass the parent, it can do the work for
   you.
Manu Sporny:  I'm wary of putting the feature at risk because
   we've done the work.
Gregg Kellogg:  JSON-LD is a better spec w/o property generators,
   we should mark them as at-risk. [scribe assist by Manu Sporny]
Niklas Lindström:  the amount of work put into it is an
   indication of how complex it is.
Markus Lanthaler:  implementing the algorithms doesn't mean that
   someone knows what's actually going on.
Gregg Kellogg:  I'm concerned about removing such a big
   feature... we don't have a way of doing that if we remove the
   feature. [scribe assist by Manu Sporny]
Manu Sporny:  we need the correct text if we're going to take it
   to LC. If it's going to be dropped, we can just stop discussion.
Manu Sporny:  the timing is the thing.
   … This would delay LC while we re-write the algorithms, after
   asking lin and scor.
Markus Lanthaler:  perhaps just talk about things other than
   property generators?
Manu Sporny: 5.13 Term Selection Subalgorithm, second checkbox
Markus Lanthaler:  dave used this to say if it is explicitly set
   to null or something else. I think it would be easier to just use
   @null.
Dave Longley:  I think there was a test-case where the difference
   in language mattered; perhaps default language.
Markus Lanthaler:  my algorithm is almost exactly the same, and I
   just use @null. I can't see where it would actually matter.
Dave Longley:  if there were two terms, one used a null language,
   and the other didn't, you'd need to be sure you didn't loose
   that.
   … It might be to simplify existence checks. We could change to
   check for existence of entries instead.
   … I'll take a look at it and try to clean it up.
Markus Lanthaler:  next comment is if variables should be
   different.
Manu Sporny:  to address your concern about copy/paste into
   comments, they should add quotes to make sure it's clear.
Dave Longley:  this was brought up by prototypo, I just want to
   be sure it's covered.
Manu Sporny:  we could update ReSpec to add hidden back-ticks
   around variables, so that they show up when copy/pasting.
Gregg Kellogg:  I'll look into supporting something that makes
   this simpler in ReSpec [scribe assist by Manu Sporny]

ACTION: Gregg to look at adding support in ReSpec for auto-quoting
variable names in algorithms.

Next up: 5.14 Value Compaction
Dave Longley:  I think it was a difference of opinion on what the
   style should be.
   … One does a copy, the other doesn't and doesn't change things
   until it needs to.
Markus Lanthaler:  let's just not discuss value compaction now.

Topic: JSON-LD Property Generators

Manu Sporny:  it sounded like there was concensus to remove
   before LC.
   … We should discuss with scor and lin, but the group would
   like to remove it due to the great complexity added.
Paul Kuykendall:  how would this affect the actual RDF being
   created? Is it just a shortcut to not have to repeat yourself.
   … I see that we have a use-case that could make use of this,
   for example, when building out ontologies so that we can merge.
Markus Lanthaler:  use case has to do with transforming to RDF?
Paul Kuykendall:  we're using JSON-LD more like JSON/RDF
   structure. We're generating some ontologies that define the
   business domain and trying to tie them to other existing
   ontologies (dc, schema, etc.).
   … to allow customers better access into the data.
   … For example, we have our own internal structure for
   "address", which has a lot of cominality, using sameProperty
   within the ontologies, that is expressed in the code.
   … To say that these are the same thing.
   … We to SPARQL inference in the client, and they then parse
   out what they need.
Dave Longley:  is it read-only?
Paul Kuykendall:  they can write back. It may be SPARQL Update in
   the future.
Gregg Kellogg:  Well, the support you're showing for it might
   mean we have to keep this feature... even if we don't like it
   that much. [scribe assist by Manu Sporny]
Markus Lanthaler:  you said you're defining ontologies, and
   mapping them to DC, Schema and so forth?
Paul Kuykendall:  yes; However, the clients don't necessarily
   know about this mapping, as we can hide things behind the scene.
   … If it turns out that they're really a bad idea, it's early
   enough in our cycle that we could change.
Markus Lanthaler:  the only change, if we drop property
   generators, you would have to be explicit about having three
   different properties.
Paul Kuykendall:  the concern is that you have data-duplication
   that it populates all of them and reduces the chanse of
   programmer error.
   … Making sure that all copies are updated, rather than just
   one of three copies.
Markus Lanthaler:  one of the problems with PG's is that if the
   client expands and only changes one of the values, it wouldn't
   compact back again.
Niklas Lindström:  it is duplication, just hidden.
Paul Kuykendall:  we use compacted form between client and
   server.
   … If I had the incorrect notion, maybe we should take this
   out, so we don't have a mis-interpretation.
Dave Longley:  there is nothing passed to tell how to re-compact,
   just the values need to be the same.
Niklas Lindström: ..
   http://www.w3.org/TR/rdfa-syntax/#vocabulary-expansion
Paul Kuykendall:  that sounds like a great reason to get rid of
   them, as it might be deceptively simple and create more problems
   later on.
Niklas Lindström:  describes RDFa mechanism for vocabulary
   expansion.
Paul Kuykendall:  My mis-understandings implies that other people
   might also be confused about property generators.
Manu Sporny:  there is no easy solution to your use-case. The
   alternatives might actually be worse than property generators.
Markus Lanthaler: hi lin
Markus Lanthaler: we are currently discussing whether to drop
   property generators for 1.0
Dave Longley:  either way, your application is going to have to
   keep track of what properties go together.
Manu Sporny:  Wondering about possible future use of
   property-generators in Drupal.
Lin Clark:  at this point, I don't think they're a requirement
   for us.
   … We're focusing our use of JSON-LD to aligning ...
   … We're not necessarily optimizing for smaller size, so it
   should be okay from our stand-point.
Manu Sporny:  seems like paul has a use case, but PGs don't fully
   express it, and there is a fair chance of making things worse.
   … Lin's use case has found a different solution.
   … At this point, it doesn't seem we have anyone that really
   needs them.
Markus Lanthaler:  easier to remove now and re-introduce later
   than the other way around.
Niklas Lindström:  they border so much on semantics, that people
   can use things like vocabulary expansion to do the same thing.
   It's not syntactic, but semantically, it's already defined.
Dave Longley:  I think the only way for them to work in the
   future if we allow updates would be to include something in
   expanded form, but for everyone converting to RDF, it wouldn't
   work.
   … People would have to program to understand the special
   relationships between properties.

PROPOSAL: Remove Property Generators from JSON-LD before Last
   Call due to no developers needing the feature, the feature having
   a high potential of misuse, and because of the complexity it adds
   to the specification.

Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1
Niklas Lindström: +1
Paul Kuykendall: +1

RESOLUTION: Remove Property Generators from JSON-LD before Last
   Call due to no developers needing the feature, the feature having
   a high potential of misuse, and because of the complexity it adds
   to the specification.

Topic: ISSUE-221: Inverse properties in JSON-LD

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/221
Manu Sporny:  a new feature requested, with a couple of
   implementations.
   ... Of course, we're well past feature-freeze, even if they
   seem simple to add.
Niklas Lindström:  I've been using it since 2011, and at the
   National Library I come across it all the time.
   … Today, we abstracted people for which there exist not
   descriptions, but we want to record the relationship anyway. For
   example createorOr. There are no such properties, so using
   ^creator allows us to express this.
   … Not all vocabularies define inverse properties, and certain
   disciplines frown on explicitly defining inverses of properties.
   … you naturally create things over time, you link a book to an
   author, and don't always update the author to link back to the
   book.
   … I've felt needs for links to objects, such as RDF/SPARQL
   Constructur results, or CBD's, where I want to root the
   description in the primary object, and have things that link
   to/from this.
   … Filter authors/works, and works/authors. In many
   expressions, it's useful to say the inversee.
Gregg Kellogg:  Curious if you've implemented the round-tripping
   bits of this? [scribe assist by Manu Sporny]
   … I haven't implemented round-tripping in the code I have so
   far. It's been a while, and I think I had something working in
   the past.
   … It seemed fairly simple to do, as long as you don't define
   both to and from forms.
Markus Lanthaler: http://bit.ly/Xfy5vO
Markus Lanthaler:  I implementier compaction, and it's quite
   triveal.
   … (example provided.)
   … children expands to parent.
   … It also takes into consideration if there is @reverse in the
   data.
Niklas Lindström:  this cleanly solves the two variants I had in
   the past, but this is cleaner.
   … I'd like to see it as you've implemented it.
Paul Kuykendall:  we also have some use cases we're using on
   where we need support for inverse relationships.
   … We had to do a work around where we do inferencing on the
   client side to look for inverse relationships, so it can
   understand what properties to set.
   … We do have a way around it, but this would be a nice to have
   feature.
   … We have a (barley adequate) workaround, but we need
   something different.
Manu Sporny:  would it be enough to create a description of how
   it works, not include in JSON-LD 1.0, but all implementations
   have the feature.
   … Or, we have an implementation, and Markus could put his
   algorithm in there, but we run a risk of standardizing something
   that doesn't work for everyone.
Gregg Kellogg:  I'm concerned that we might be putting this into
   the spec before it's ready. I have some other feature additions
   that might need further thought. Trying to solve everything at
   this point is a recipe for disaster. I think we need to embrace
   an "open specification" approach, and close the door on JSON-LD
   1.0 Core in order to allow in order for people to start using it.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  We can start adding features after that... easier
   to put it in later than add it in now and possibly remove it
   later. [scribe assist by Manu Sporny]
Niklas Lindström:  it isn't new from my perspective, and is a
   very natural feature when you express graphs as trees.
   … We also have the BBC use, which is what brought this up.
Manu Sporny:  would having it spec'd out elsewhere be enough?
   … How many years before JSON-LD 1.1?
   … If it's broadly implemented, it doesn't really matter if
   it's in the core spec.
Markus Lanthaler:  other specs would not be compliant, as they
   must otherwise drop such properties or values.
   … There are some special cases (no @id and @reverse), but it's
   about an afternoon to make it solid.

PROPOSAL: Put JSON-LD Inverse Properties into the JSON-LD 1.0
   specification as an at-risk feature.

Manu Sporny: -0.6
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg:  +0.2
Dave Longley: +0.5
Paul Kuykendall: +.5

RESOLUTION: Put JSON-LD Inverse Properties into the JSON-LD 1.0
   specification as an at-risk feature.

Topic: ISSUE-223: JsonLdOptions base vs. @base

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/223
Manu Sporny:  since we have @base keyword, should we have
   something you can pass into the API?
   … I think so, but @base always overrides this.
Markus Lanthaler:  what is @base used for in JSON-LD? Is it also
   used for compaction?

PROPOSAL: 'base' (passed in via the API) sets the document base,
   @base (in the document) overrides any value set by 'base' (passed
   in via the API).

Gregg Kellogg: +1
Manu Sporny: +1
Paul Kuykendall: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1

RESOLUTION: 'base' (passed in via the API) sets the document
   base, @base (in the document) overrides any value set by 'base'
   (passed in via the API).

Dave Longley:  I think we should allow the empty string ("") be
   specified, so that you can say there is no base.
Gregg Kellogg:  I use stuff like that to specify that things
   should be able to be expressed via relative IRIs... it makes the
   document work if it's served via any location. [scribe assist by
   Manu Sporny]
   … this would allow for the use of IRIs, so you'd keep relative
   IRIs.
   … (reverses scribe's understanding).
   … If you use @base "" it means to not change them, relative
   IRIs come in and go back out, for example in @id.
Markus Lanthaler:  What happens if you do this?
   '../test/.../hello' does it get compacted to this? '../hello' ?
   [scribe assist by Manu Sporny]
Dave Longley:  should be no changes. If you specify @base: "",
   make no changes to IRIs on input.
   … This does not rule out using terms and @id.
   … My preference is to do no processing at all; a way of saying
   "don't touch my IDs"
Manu Sporny:  I don't know how standard this is, how many other
   serializations say don't touch IRIs.
   … Not doing path normalization might be a problem.
Markus Lanthaler:  can we stay silent?
Manu Sporny:  we need a test-case for it.
Niklas Lindström: .. "you can also pass an empty string and see
   what happens" ;)
Dave Longley:  if we do this sort of normalization, it will
   impact normalization algorithms.
Markus Lanthaler:
   http://tools.ietf.org/html/rfc3986#section-5.2.2
Markus Lanthaler:  my read of the specs, is that paths would be
   resolved.
Dave Longley:  we link to the spec, and say that.
Markus Lanthaler:  process them as they're always processed in
   JSON-LD.

PROPOSAL: Allow @base to be set to the empty string. If @base is
   set to the empty string, relative IRIs are processed according to
   RFC 3986 Section 5.2.2 (which is how they're always processed in
   JSON-LD).

Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
Paul Kuykendall: +1

RESOLUTION: Allow @base to be set to the empty string. If @base
   is set to the empty string, relative IRIs are processed according
   to RFC 3986 Section 5.2.2 (which is how they're always processed
   in JSON-LD).

Topic: JSON-LD latest API issues

Paul Kuykendall: Is the diff-marked version broken here?
   http://json-ld.org/spec/latest/json-ld-api/
Manu Sporny: The diff-marked version for the live spec is always
   broken, you can try using the 'diffmark tool' in the live version
   of the spec.
Markus Lanthaler: Try doing this: CTRL+SHIFT+ALT+S then click on
   'diffmark'
Paul Kuykendall:  we're fixing our APIs to be closer to the
   latest spec, would be nice to know what changed.
Manu Sporny:  You're probably going to have to save a local copy
   and run the 'htmldiff.pl' script between the version you used to
   implement and the current version (saved as a static file via
   CTRL-SHIFT-ALT-S).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/
Received on Tuesday, 5 March 2013 17:26:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:54 GMT