JSON-LD Telecon Minutes for 2013-07-16

Thanks to Dave Longley for scribing. The minutes from this week's
telecon are now available.

http://json-ld.org/minutes/2013-07-16/

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

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-07-16

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0076.html
Topics:
   1. ISSUE-276: Convert appendices into normal sections
   2. ISSUE-279: Extraneous data after flattening bug
   3. RDF WG ISSUE-132: Blank node predicates
   4. Review: Uncategorized JSON-LD github issues
   5. Review: JSON-LD Syntax issues
Resolutions:
   1. Convert normative appendices A, B, and C to normal
      normative sections, leaving them at the same location in the
      document.
   2. Fix a bug in the flattening and fromRDF algorithm by not
      promoting undescribed nodes or datatypes to subjects during the
      flattening/fromRDF algorithms.
   3. Graphs are not free-floating nodes and should not be
      removed during the flattening or fromRDF algorithm.
   4. Add an option to produce "extended RDF", which defaults to
      false. If the option is true, "extended RDF" will be produced,
      retaining triples that have blank nodes as predicates. If the
      option is false, standard RDF will be produced and triples with
      blank node properties will be discarded.
   5. When mapping properties, if the author is not yet ready to
      commit to a stable IRI, suggest mapping the property to an IRI
      that is documented as unstable.
   6. Link all Basic concept sections to the Advanced Concepts
      section to ensure that readers understand that there are more
      advanced concepts associated with the basic features of JSON-LD.
Action Items:
   1. Markus to update algorithms to handle filtering.
Chair:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Manu Sporny, Dave Longley, David Booth, Markus Lanthaler, Gregg
   Kellogg, Niklas Lindström, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-07-16/audio.ogg

Manu Sporny: Some JSON-LD news, a graph database engine just put
   in native support for JSON-LD. The Activity Streams 2.0 work has
   adopted JSON-LD as a way of publishing activity stream data,
   which is great.
Markus Lanthaler: Link to graph database supporting JSON-LD:
   https://github.com/mcollina/levelgraph-jsonld
Manu Sporny: Discussion about Activity Streams 2.0 work using
   JSON-LD compatible format. Publishing JSON-LD context.
Dave Longley is scribing.
Manu Sporny:  [discusses agenda items] we have an addition from
   niklas about what we should do with the flattening algorithm
David Booth:  i wanted to propose a suggestion for how we deal
   with blank nodes as predicates as well
Manu Sporny:  let's deal with niklas' flattening algorithm first
   then bnodes as predicates and then we'll deal with David Booth's
   issue and then review the other issues

Topic: ISSUE-276: Convert appendices into normal sections

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/276
Manu Sporny:  this has to do with converting appendices into
   regular sections -- the primary argument for this is that the
   appendices are very normative sections and appendices may be
   considered "additional" info, so instead let's make them regular
   sections since a lot of normative stuff is in there
Dave Longley:  i dont' think we should move them around
   (ordering), but changing them to regular sections is fine
Manu Sporny:  yeah, the proposal is to leave them exactly where
   they are
Markus Lanthaler:  i'd be fine with that change
Gregg Kellogg:  the reference would be to dan connolly's advice
   which is that the doc should read the same if the appendices were
   removed
David Booth: +1 to Dan Connelly's advice
Manu Sporny:  it would be A, B, and C, we'd leave appendix D the
   same
Gregg Kellogg:  so there would be some movement because we'd move
   appendix D (it becomes appendix A) after appendix C

PROPOSAL: Convert normative appendices A, B, and C to normal
   normative sections, leaving them at the same location in the
   document.

David Booth: +1
Dave Longley: +1
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1

RESOLUTION: Convert normative appendices A, B, and C to normal
   normative sections, leaving them at the same location in the
   document.

Topic: ISSUE-279: Extraneous data after flattening bug

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/279
Manu Sporny:  niklas has written up the "problem" with the
   current flattening algorithm, some see it as a good feature
   others see it as a bad feature
Manu Sporny:  niklas has placed an interesting example into the
   tracker to demonstrate the downside of the current algorithm
Manu Sporny:  so the question is whether or not we see this as a
   bug in the flattening algorithm or not, fixing the bug would
   result in not promoting things that are "leaves" -- things are
   only at the top level
Gregg Kellogg:  the same thing goes for the fromRDF algorithm
   which generates the same footprint
Markus Lanthaler:  is it worth changing at this stage if you can
   just filter the data out later?
Manu Sporny:  my position is that we want to do whatever the
   majority of devs want, if they all have to filter this stuff out
   then we should probably have made things filtered out by default
Manu Sporny:  i do think it's strange to have datatypes as nodes
   in a flattened graph and that it does make things a bit messy
Manu Sporny:  i haven't experienced datatypes as nodes using
   other syntaxes/APIs/etc
Manu Sporny:  i think it will be more rare to try and get the
   number of subjects vs. getting all the nodes flattened out so
   they can iterate through them
Manu Sporny:  i think it's worth fixing it at this point since
   fixing it later would be more difficult, adding it would be
   easier later if we really need it
Manu Sporny:  so i'd lean towards removing these extraneous nodes
Gregg Kellogg:  if require our algorithms to have this data now
   we remove the ability to clean it up later because people will
   come to depend on it
Gregg Kellogg:  should we mark this at-risk?
Gregg Kellogg:  there's a danger that someone could argue this is
   a normative change, etc.
Manu Sporny:  well, i think it's a bug and the other argument
   that it's not a substantive change because we're doing CR and the
   algorithms are really for review there and the true test is if CR
   implementors think this was a good change, etc. -- at this point
   this was a bug that was put in the spec that was part of a
   rewrite, we're putting it back how it was and marking it at-risk
   if implementors feel it should be done another way
Manu Sporny:  sound reasonable?
Gregg Kellogg:  yes

PROPOSAL: Fix a bug in the flattening and fromRDF algorithm by
   not promoting undescribed nodes or datatypes to subjects during
   the flattening/fromRDF algorithms.

Gregg Kellogg: +1
Dave Longley:  +0.5
Niklas Lindström: +1
Manu Sporny: +0.7
Markus Lanthaler: +1

RESOLUTION: Fix a bug in the flattening and fromRDF algorithm by
   not promoting undescribed nodes or datatypes to subjects during
   the flattening/fromRDF algorithms.

Markus Lanthaler:  how are we going to filter them out? leave
   them out of the node map or not?
Dave Longley:  There is another reason we want to do that - the
   framing algorithm relies on the node-map algorithm, so we should
   have them in the node map. [scribe assist by Manu Sporny]
Gregg Kellogg:  i think we used to do it with them in the node
   map and we just removed them later
Gregg Kellogg:  i think there's no problem with adding things to
   the node map
Niklas Lindström:  the node map is just an internal state, so
   when adding properties to things in the node map you add them to
   the array which is cleaner than filtering at the end, i think
Niklas Lindström:  you can build the node map and the flattened
   array at the same time
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-api/#flattening-algorithm
Manu Sporny:  would making that change complicate the algorithms?
Markus Lanthaler: For each id-node pair in graph ordered by id,
   add node to the @graph member of entry. State that node needs to
   have other properties than @id
Dave Longley:  i don't think we should leak the flattening info
   into the node map algorithm because it complicates things, but we
   could mention the optimization
Markus Lanthaler:  i think we only need to add some words to the
   flattening algorithm
Gregg Kellogg:  fromRDF just removes some steps
Manu Sporny:  markus, do you have an idea for what changes to
   make?
Markus Lanthaler:  yeah, for flattening yes, i can look at the
   RDF one, shouldn't be too difficult
Manu Sporny:  can you take a shot at that?

ACTION: Markus to update algorithms to handle filtering.

Gregg Kellogg:  what about graphs with no data in it?
Manu Sporny:  well there's an argument to remove it based on how
   people will use flattening
Gregg Kellogg:  well, i think an empty graph is actually data and
   there's value in retaining that
Gregg Kellogg:  i think there's value to keeping that information
   in a flattening representation
Dave Longley:  There may be an additional problem here - there
   may be disjoint information in the graph. [scribe assist by Manu
   Sporny]
Dave Longley:  If we remove them at the top-level, they'll cease
   to exist entirely in the flattened output. If there is no
   reference to something in the graph, we'll lose it. [scribe
   assist by Manu Sporny]
Dave Longley:  This may be more complex than we want it to be -
   we have to make sure that the things we're removing aren't
   referenced from anywhere else. [scribe assist by Manu Sporny]
Markus Lanthaler:  We already remove free-floating nodes, right?
   [scribe assist by Manu Sporny]
Niklas Lindström:  An empty graph sounds like a covert delete to
   me. [scribe assist by Manu Sporny]
Gregg Kellogg:  I don't think we can do that, you can't actually
   say in RDF that a graph is referenced. The name of the graph does
   not semantically relate to the use of that name in a triple
   somewhere else. [scribe assist by Manu Sporny]
Gregg Kellogg:  The fact that a graph has a name and is free
   standing and not referenced does not have an impact on the RDF
   Dataset model [scribe assist by Manu Sporny]
Dave Longley:  That's true, but we wanted to take a different
   direction in JSON-LD. It's more useful to say that the name of a
   graph does have meaning. As it appears in the JSON, it does seem
   to have meaning. [scribe assist by Manu Sporny]
Niklas Lindström:  We can leave it as-is, and not extend anything
   in ISSUE-279, leaving graphs alone. [scribe assist by Manu
   Sporny]
Manu Sporny:  can these empty graphs even appear in the fromRDF
   algorithm?
Gregg Kellogg:  it's possible that the input specifies an empty
   graph

PROPOSAL: Graphs are not free-floating nodes and should not be
   removed during the flattening or fromRDF algorithm.

Manu Sporny: +0.6
Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +0.75
Markus Lanthaler: +0.7

RESOLUTION: Graphs are not free-floating nodes and should not be
   removed during the flattening or fromRDF algorithm.

Topic: RDF WG ISSUE-132: Blank node predicates

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/132
Manu Sporny:  so we've moved away from skolemization for bnodes
   as predicates, dbooth has been talking about using relative IRIs
David Booth:  coming into this was that there was an important
   use case as using bnodes as predicates which is why i recommended
   skolemization
David Booth:  when i looked into the use cases i became more and
   more convinced that other approaches would be better
David Booth:  the overriding motivation would be to make
   transitioning from JSON to JSON-LD easier, which i agree with
   that motivation
David Booth:  i've tried to point out other ways that these use
   cases could be addresses, but people seemed to be attached to
   using bnodes here so i'd just propose that we have an option that
   defaults to false that, when true, will produce generalized RDF,
   when false it will drop bnodes as predicates
David Booth:  [missed some comments]
David Booth: 1. Add an option to produce "extended RDF", which
   defaults to false. If the option is true, "extended RDF" will be
   produced, retaining triples that have blank nodes as predicates.
   If the option is false, standard RDF will be produced and triples
   with blank node properties will be discarded.
David Booth: 2. Suggest other ways to handle JSON properties that
   the author is not yet ready to map to stable IRIs, such as: (a)
   mapping them to unstable IRIs and documenting the fact that those
   IRIs are unstable; or (b) mapping them to "" (or such) to prevent
   them from appearing in the resulting RDF. Consumers that need
   those property values can obtain them at the JSON level (and if
   desired could then inject those values into the RDF without us
David Booth: ing blank node predicates).
Manu Sporny:  i'd be happy with that change
Manu Sporny:  i think adding the option and having it default to
   false will address what both sides want
Manu Sporny:  and it would be good to provide suggestions for
   what authors can do if they want to do this kind of mapping
Gregg Kellogg:  regarding unstable IRIs are you suggesting we
   mint a new IRI scheme for unstable IRIs?
David Booth:  that's a possibility, my own view is that if people
   are using a documented unstable feature that's their mistake
David Booth:  certainly people can document the fact that certain
   things are stable or unstable, and they are getting out-of-band
   information from them then they ought to read the documentation
   anyway
Manu Sporny:  the only downside to minting a new scheme is making
   more work for the group and i can see people wanting us to create
   this for all RDF datasets, etc.
Manu Sporny:  there would be extra work/overhead, that's the
   strongest argument against it
David Booth:  if it were something registered it would just be a
   general-purpose schema that anyone could use for the purpose of
   unstable iris
Niklas Lindström:  i agree with dbooth regarding the fact that
   people should pay attention to documentation, but in practice it
   doesn't always happen and there are cases where there have been
   issues with this

PROPOSAL: Add an option to produce "extended RDF", which defaults
   to false. If the option is true, "extended RDF" will be produced,
   retaining triples that have blank nodes as predicates. If the
   option is false, standard RDF will be produced and triples with
   blank node properties will be discarded.

Gregg Kellogg: +1
Niklas Lindström: +1
Dave Longley: +1
David Booth: +1
Manu Sporny: +0.8
David I. Lehn: +1
Markus Lanthaler: +0.8

RESOLUTION: Add an option to produce "extended RDF", which
   defaults to false. If the option is true, "extended RDF" will be
   produced, retaining triples that have blank nodes as predicates.
   If the option is false, standard RDF will be produced and triples
   with blank node properties will be discarded.

David Booth:  i think there may be more push back from the web
   community for minting an unstable iri scheme
Manu Sporny:  so in general, map bnodes predicates to an unstable
   IRI, one way is to use a document-relative fragment identifier
Markus Lanthaler:  i think that might be confusing because you'd
   use those for stable IRIs too
David Booth:  the point of the second suggestion was not to be
   prescriptive but instead to provide ideas for what devs could do
   to deal with this
[discussion about possible suggestions to make to devs for what
   to do with bnode predicates]
Markus Lanthaler:  can we just be silent on it? we don't
   recommend bnode predicates
Manu Sporny:  i think it's come up so often we should mention
   something
David Booth:  maybe just to suggest mapping to unstable IRIs and
   document or leave them unmapped
Gregg Kellogg:  i think the people that can do that are capable
   of mapping to RDF without having to do unstable, etc.
Gregg Kellogg:  i think this is for people who are just getting
   into this
Gregg Kellogg:  i think we can just say that properties that
   aren't mapped are dropped
Manu Sporny:  so we cover the case where things are unmapped
   that's already talked about in the spec so this may be a case
   where the author wants to preserve the data but not in a
   permanent way
David Booth:  yeah, they don't want to throw away the data but
   they aren't yet ready to commit to a stable IRI
David Booth:  that's the use case i've heard
Gregg Kellogg:  aren't there owl annotations that could be used
   here
Niklas Lindström: .. vs:
   http://www.w3.org/2003/06/sw-vocab-status/ns#
Manu Sporny:  i think that in this case the author doesn't want
   to go through the trouble of even documenting the vocabularies
   that they're using
Manu Sporny:  they just dont' want the data to disappear but they
   want it to be recognized as unstable
David Booth: When mapping properties, if the author is not yet
   ready to commit to a stable IRI, suggest mapping the property to
   an unstable IRI and document the fact that the IRI is unstable.

PROPOSAL: When mapping properties, if the author is not yet ready
   to commit to a stable IRI, suggest mapping the property to an IRI
   that is documented as unstable.

Manu Sporny: +0.7
Gregg Kellogg: +1
Dave Longley:  +0.7
Markus Lanthaler: -0.8
David Booth: +1

RESOLUTION: When mapping properties, if the author is not yet
   ready to commit to a stable IRI, suggest mapping the property to
   an IRI that is documented as unstable.

Topic: Review uncategorized JSON-LD github issues

Manu Sporny:

https://github.com/json-ld/json-ld.org/issues?milestone=none&page=1&sort=created&state=open
Manu Sporny:  ok, let's go through all of the github issues and
   make sure we cover whatever needs covering before CR
[discussion about which issues to push off/schedule for
   discussion]
Gregg Kellogg:  if json-ld contexts could be extracted from
   script tags that would be a useful feature
Gregg Kellogg:  it would be helpful with activity streams
Manu Sporny:  i'd feel more comfortable giving advice on how to
   host and load contexts on the json-ld.org site because we don't
   know what best practice is yet
Gregg Kellogg:  i agree, or it goes into some form of a best
   practices document that emerges
Gregg Kellogg:  with regards to the other sort of profile that
   i'd been suggesting we might want to allow a community to sort of
   create other specifications to be implemented that could be
   folded into jsonld.next
Dave Longley:  We should link to the advanced Context section
   from the basic context section. [scribe assist by Manu Sporny]
David I. Lehn:  Yeah, I suggest that in the issue. [scribe assist
   by Manu Sporny]

PROPOSAL: Link all Basic concept sections to the Advanced
   Concepts section to ensure that readers understand that there are
   more advanced concepts associated with the basic features of
   JSON-LD.

Markus Lanthaler: +0.5
Dave Longley: +1
David I. Lehn: +1
Manu Sporny: +0.6
Gregg Kellogg: +0.5

RESOLUTION: Link all Basic concept sections to the Advanced
   Concepts section to ensure that readers understand that there are
   more advanced concepts associated with the basic features of
   JSON-LD.

Group goes through the rest of the issues and asserts that they
   do not affect the syntax or API specs.

Topic: JSON-LD Syntax issues

Markus Lanthaler:

https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&sort=created&state=open
Manu Sporny:  We still need to discuss issues 274, 263, and apply
   editorial changes in 254. We'll chat next week about API issues
   and RDF WG issues.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 16 July 2013 16:23:21 UTC