Miinutes from Nov 08 TPAC session

Last Wednesday, we met for an update on work on JSON-LD. Minutes are here inline, and available on the web site [1] (although it’s not syncing at present).

Some takeaways:

* There is concern about requiring the @version announcement breaking 1.0 processors, particularly as schema.org does not actually process a context document.
  * Separate discussions suggested that we might add a version attribute to the mime-type used in the script tag, along the lines of type=“application/ld+json;version=1.1”.
  * For a breaking change, we should probably use a major version change, such as 2.0, although this may be treading on a future WG.
  * New features not likely to affect schema.org context, in the near term, as long as they can recognize when such features are in use.
* Some thoughts as to a WG which could adopt JSON-LD work were discussed, including a possible new WG for “Data on the Web Best Practices”, but the group should probably work on a SOW to create it’s own group.
* New features were received well, but nobody likes the @nest keyword, so issue 246 has been re-opened [2]
* More focus on allowing contexts to be pre-distributed and/or cached indefinitely as non-modifiable.
  * @sandro suggested “Sub-Resource Integrity”[3], which would require syntax extensions to be able to describe all the attributes.

Gregg Kellogg
gregg@greggkellogg.net

[1] https://json-ld.org/minutes/2017-11-08/
[2] https://github.com/json-ld/json-ld.org/issues/246
[3] https://www.w3.org/TR/SRI/

JSON-LD Community Group Telecon Minutes for 2017-11-13

Agenda:
   https://www.w3.org/wiki/TPAC/2017
Chair:
   Gregg Kellogg
Scribe:
   Robert Sanderson
Present:
   Gregg Kellogg, Robert Sanderson, Kim (Hamilton) Duffy, Benjamin 
   Young, David Wood, Ivan Herman, Manu Sporny, Fabien Gandon, 
   Christopher Webber, Dave Longley
Robert Sanderson is scribing.
Gregg Kellogg: Slides for this presentation are at 
   https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/
Kim (Hamilton) Duffy: present+
Benjamin Young: present+
David Wood:   Are the additions just supplementary, or changes 
   semantics?
present+
present+
Gregg Kellogg:  Only additions.
   ... Previously container was limited to 4 values. Now we have 
   a new value space for container.
   ... so for compatibility, a 1.1 processor and sees it in 1.0 
   mode will complain
David Wood:  Versioned MIME 1.0 -- intention to later come up 
   with 1.1.  Unexpectedly, the process of versioning caused MIME to 
   never increase its version
   ... built into so many tools
Ivan Herman: present+
   ... With schema.org and other usage, what barriers are there 
   practically for adoption?
   ... brought up a couple already, are there others?
depending on what could be broken when 1.0 processors read 
   @version 1.1, maybe it would make sense to use 2.0 instead of 1.1
depends on expectations
Gregg Kellogg:  New keys can confuse 1.0 and 1.1 implementations. 
    If this property was used, 1.1 would interpret the data 
   differently
   ... need to face what that means as a community.  Far fewer 
   implementations of the processor than the uses of the language, 
   we could choose to simply say we're cutting off the 1.0 features 
   or restrictions
Ivan Herman:  Far fewer code implementations, but no idea how 
   often it's used.  Forcing an upgrade
Manu Sporny:  Kingsley sent me an email 2 days ago, just tried 
   yoru 1.1 context and it blew up on me. ... what are we doing?
   ... that was a good thing as it was a 1.0 processor
   ... Good for it to blow up as there are features we absolutely 
   need
   ... His digital signature would be just wrong
Gregg Kellogg:  How does a CG manage it?  Need a working group.
???" RDF 1.1 was a WG though
David Wood:   Was standardized in a WG
Ivan Herman:  Don't see a problem
Ivan Herman:  If its successful, take it to WG and the version 
   will be decided
   ... agree with alexandre that 2.0 sends a new message
Benjamin Young: +1 to calling it 2.0 (or just 2)
   ... rdf 1.1 is incremental, nothign radical
Fabien Gandon:  it is ok to do 1.1 or 2.0 in a CG or WG [scribe 
   assist by Fabien Gandon]
Christopher Webber:  Agree with Manu that it should have blown up 
   in that circumstance
   ... don't want someone using schema who it was using it in 
   prod, don't want it to randomly blow up
   ... learnt lesson in activitypub/streams, if you add a new 
   term to a context, and had a cached context, it wouldn't validate
   ... doesn't change this, but might be worth encouraging. Good 
   to version contexts... schema.org + some version identifier.  Can 
   wait to update to that version when your code is ready
   ... should start pushing more
Kim (Hamilton) Duffy:   Abstracted from just JSON -- does that 
   change RDF canonicalization
David Wood:  I did not pay her :D
Gregg Kellogg:  canonicalization happens at the rdf abstract 
   model level
   ... if your data is in YAML, you might eg have whitespace 
   issues ... but also in RDF/XML
   ... no different barriers
   ... turning JSON-LD into RDF for normalization goes through 
   the algorithms that parse the syntax into an intermediate form, 
   that you then run alogithms on
   ... just a different surface syntax.  Can be used where the 
   target model can go to that structure
David Wood:   What about framing?
Ivan Herman:  just syntactic sugar.
Gregg Kellogg:  Can be used to filter
Dave Longley:   If you filter, you can change the canonical 
   representation by filtering
Gregg Kellogg:  Included the index which does not round trip
Ivan Herman:   JSONLD for me is yet another RDF serialization.
   ... Still true?
Dave Longley:  Yes
Benjamin Young:  But not round trip everything like index
present+
   ... (round tripping meaning)
Gregg Kellogg:  Definitely need to leave it as an issue. Good 
   discussion here, in issue, and hopefully in a WG
Reto Gmür: One issue was a huge file that couldnt' be parsed.  Worked 
   with a developer, JSON-LD looks a bit different, then people have 
   a problem.  Google structured data -- put examples in and there 
   are errors
   ... if you look at it like JSON, then can be surprised when 
   things can mean the same thing and look differently
Ivan Herman:  Two JSON-LD are equivalent if the RDF is euivalent, 
   but files can be very different
   ... hard to understand if you don't have the background
David Wood:  JSON and JSON-LD have idfferent data models -- LD is 
   explicit, JSON is implicit
Gregg Kellogg:  (slides)  ID maps -- keys of URIs that reference 
   the description of the identified resource
   ... these are equivalent to an array of two objects with @id 
   in the objects
   ... round trippable. If you compact with a context that 
   doesn't have a container id, then you get array. If you add it, 
   you get the object
???: That's by virtue of the URL?
Gregg Kellogg:  The @container: @id makes this explicit
Gregg Kellogg:  Also a parallel that lets you have container type 
   -- the indexes are treated as the value of @type for the object
Dave Longley:  graph container as well
Gregg Kellogg:  nested properties -- microdata representation has 
   JSON structure between entities and properties
   ... so added a sugary nesting property.  labels: @nest means 
   when you expand the data, collapse the values back to the entity
Ivan Herman:  What does it mean?
Gregg Kellogg:  Ignore the nesting
Dave Longley:   labels has no meaning in the data model.
Gregg Kellogg:  an object with two labels.
Benjamin Young:  really valuable -- run into this in JSON a lot 
   -- want it packaged in this way for devs
Ivan Herman:  something like comments or annotations
david, dlongley: a sturctural comment
(...) discussion about @nest as a name
Drummond Reed: Strictly for the format
   ... are there other things like that?
Gregg Kellogg:  Other things are to take json idioms
   ... and generally round trip
   ... this won't survive a round trip
Reto Gmür: Would it make sense to have the labels (?)
Christopher Webber:  Can definitely see using this
   ... if you have two of them, and they have the same keys, do 
   they go?
Gregg Kellogg:  No, you end up in an array. Just not round trip 
   to the right places
   ... another way to have a term with a nested key, that does 
   allow round tripping
Gregg Kellogg:  Scoped contexts
   ... Very cool and easy to do.  Define a context within a term 
   definition, so when you see the term, it is as if the context is 
   inserted within the term
(everyone): Oh yes. This. This.
Gregg Kellogg:  So the context comes into play for values of the 
   term. Name is Manu at the top level, then an interest which has 
   two keys name and topic
   ... Now name and topic are evaluated according to foaf not 
   schema
   ... gets around the framing problem of putting contexts lower 
   down in the frame
...
   ... desire in the community, or at least a misunderstanding, 
   about what contexts are for
   ... thought if you added data to a term definition to the 
   context it would be added to the data. That's not the case
Benjamin Young:  Fixes the confusion that you're defining a term 
   globally, and name now has one meaning through out.  Fixes the 
   problem for "found json" ... others json I want to be -ld
   ... you get some snowflake json and want to make it LD, and 
   they used the same key differently
Drummond Reed:  Conflicting terms?
Gregg Kellogg:  Last context wins
/me notes that we needed something like in schema.org because of 
   some terms pointing to GoodRelations entities
   ... scoped context based on type.  Key off of @type to assign 
   the context.
   ... So the term definition is based on the @type of the 
   resource, not the key that is used to refer to it
David Wood:   didn't you throw the parser writers under the bus?
Gregg Kellogg:  it requires injecting code at the beginning of 
   expansion where we look at type. Have to look at key for 
   expansion, then also pass the context in.
So some insertion but not duplication
   ... then add code that processes the type
   ... appends the context to be used. Doesn't require two passes
Alexandre Bertails: Does order of properties matter?
Gregg Kellogg:  Does it have a key that expands to @type?
Alexandre Bertails: Can't stream the JSON though
Manu Sporny:  Wanted streaming processors to work, but couldn't 
   do it.  If you want streaming, then you do need to order the keys 
   in the right way as the publisher
Reto Gmür: Can't mandate it?
Gregg Kellogg:  No, because JSON doesn't have ordered keys.
Robert Sanderson:  ...
David Wood:  When Benjamin writes a proxy for found json, he can 
   reorder and stream :)
Gregg Kellogg:  When compacting, it was common to be surprised by 
   keys used. eg:  making a sport key, would produce sport:sEvent, 
   not sportsEvent
   ... added rules to make this more intuitive
   ... number of open issues
   ... graph container is gratuitous, for framing.
   ... add a graph container type
   ... add JSON that isn't mapped, just a literal JSON value
   ... Language maps have bugs.
   ... Request JSON-LD and a context or frame in the request
   ... eg from a SPARQL endpoint
   ... Having to download a context. Problem for Web of Things.  
   Some pre-population of contexts so act of parsing doesn't result 
   in deref
   ... DiD addresses the need?
   ... bigger issue than just JSON-LD
Manu Sporny:  JS lib lets you put in handlers for URLs to 
   pre-cache
   ... loads off of disk with these handlers
   ... for first bullet, fundamental feature for verifiable 
   claims
Christopher Webber:  Big fan of DID -- not convinced they're the 
   right way to do the issue. Content addressing?
Gregg Kellogg:  API option might address it
marisa: Unmapped JSON values -- using JSON-LD for a report format 
   for accessibility in epubs
   ... EARL is high level, need more detail
   ... if you have JSON-LD doc, and has a mix of in vocab and 
   out, is that valid?
Gregg Kellogg:  Yes, but parsing it will ignore the unknown terms
marisa: To be a good citizen, would add
Gregg Kellogg:  geojson has an incompatible structure, need to 
   keep the datatype without semantic
   ... allows round tripping the data, not the sematnics
marisa: Will move some custom terms into vocab, but too soon 
   right now
Ivan Herman:  some portions of RDF, some not.  Currently need two 
   files, one -LD and one just JSON
   ... want to do metadata in RDF, but maybe ToC is not useful in 
   RDF.  Can declare that it's not RDF
Gregg Kellogg:  hope to finish CG work in Q1 2018
   ... results at Gregg's distiller
   ... final report from CG ... but want a recommendation
   ... need to get a WG or attached to an existing one
Ivan Herman:  there isn't one coming up at the moment
will the slides be available?
   ... could force it into something but not a clean solution
   ... 1.0 was lucky that RDF wg was running
   ... today not so lucky
   ... so need to go the separate WG route
Benjamin Young:  data best practices on the web ... could have a 
   WG that vague?
Gregg Kellogg: Slides from the talk: 
   https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/index.html
Benjamin Young: gkellogg (et al): David Raggett mentioned an 
   interesting in creating a "data on the Web" WG fwiw
Gregg Kellogg: Good to know, I’ll connect. It did come up in 
   another context as one avenue.
Benjamin Young: cam up in his overview of 
   https://www.w3.org/wiki/TPAC/2017/SessionIdeas#Web_Data_Standardization

Received on Monday, 13 November 2017 22:14:45 UTC