JSON-LD Working Group Telco -- 29 Jun 2018

<leonardr> for some reason I don't have access to the list archives to get the webex info - is it somewhere else?

<ajs6f> https://mit.webex.com/mw3300/mywebex/default.do?service=1&siteurl=mit&nomenu=true&main_url=%2Fmc3300%2Fe.do%3Fsiteurl%3Dmit%26AT%3DMI%26EventID%3D664756192%26UID%3D0%26Host%3DQUhTSwAAAATND-q04y-TfLQYcgIwWGUieeEi6yOYKKQUaQQ4PwBXor1A_eer-vfo51FTJNQciSQ4zia5OZKbmdtfcrZRyr510%26FrameSet%3D2%26MTID%3Dm468ab485799df7b08cb30e07d45ab08e

<azaroth> Leonard - it should ask for your w3c account details?

<leonardr> and I entered them and it didn't like me :(

<azaroth> :(

<hsolbrig> +present hsolbrig

<azaroth> I'm pretty sure I saw the email that you'd joined the group okay, so I wonder what's up. Ivan, after the call, can you check?

<azaroth> hsolbrig: present+ rather than +present (unless that's an alias?)

<azaroth> scribenick: david_newbury

approve minutes

First topic--approving the minutes of the last call.

<bigbluehat> +1

<hsolbrig> +1

<gkelloggg> +1

<azaroth> +1

<simonstey> +1

<leonardr> 0

<dlehn> +1

<ivan> +1

RESOLUTION: last week's minutes approved

RESOLUTION: Minutes of the last call are approved

Announcements and reminders

TPAC info

Tpac: Hotel block extended through the friday night, which means that people who are leaving on Saturday (aka us) couldn't even book. That's been extended, so everyone can both register and et the hotel at the correct TPAC rate.

There are diversity scholarships available, so if there are people who are typically underrepresented in the web standards community, and would like to attend, please encourage them to apply for that scholarship fund.

next week telco

azaroth: Next week is independence day, on July 4th, is anyone then not going able to make next week's call?

leonardr: I cannot make it

azaroth: Nobody else will not be available, it seems, so we will have the call as per normal.

further introductions

azaroth: Introductions. Let's go down the list. If you were on the call, name and introductions.
... Semantic architect, J. Paul Getty Trust, co-chair

adam: Apache software foundation, as well as smithsonian

jeff: OCLC, working with semantic web for the past six years, getting linked data in OCLC's web standards, and working with Rob and others in advancing standards and the new IIIF presentation API.

benjamin: here, from Wylie

<bigbluehat> bigbluehat: Benjamin Young, John Wiley & Sons, Co-Chair of JSON-LD also participating in the Publishing WG

david_lane: working at digital bazzar

gregg kelllog: Spec Ops, and driver of JSON-lD

leonard: adobe systems, but chairs the XMP working group at the ISO, and one of the projects is to create a JSON-LD serialization of XMP, so here to participate.

simon: research scientist at Seimanns

tim: Tim Cole, University of Illinois, Urbana Champaign
... also working with the web annotation spec

<hsolbrig> harold solbrig: Mayo Clinic

azaroth: JSON-LD community group has been working on things like framing and other things

overview of the CG documents

azaroth: so, Gregg, as the main instigator of those drafts, can you go through them rapidly, since most people here understand JSON-LD 1.0 but may not have kept up with the community group changes?

<gkellogg> https://www.w3.org/community/json-ld/

gkellogg: The community group made pages, and if you open them, you'll find the updates to the 1.0 document which are obvious in a couple ways.

<gkellogg> https://www.w3.org/2018/jsonld-cg-reports/json-ld/#node-type-indexing

gkellogg: for instance, if you check a section that has changed, you'll see it's highlighted and provides a visual indicator of the parts of the spec that have been changed.

<gkellogg> https://www.w3.org/2018/jsonld-cg-reports/json-ld/#changes-since-1-0-recommendation-of-16-january-2014

gkellogg: there's also a section describing what has changed.

<gkellogg> https://json-ld.org/presentations/JSON-LD-Update-TPAC-2017/assets/player/KeynoteDHTMLPlayer.html#6

gkellogg: rather than walking through the document, I'll point to the presentation that was given at 2017 TPAC, which went over the notable changes
... principal is the version announcement, to activate the new processing model
... which announces the version 1.1. Unfortunately, 1.0 did not call out as error conditions things like containers that were out of bounds.
... so new features, such as ID container, creating ID maps, requires that the version be specified as 1.1.
... ID maps were a requested feature, previously if you have a number of different values, and you needed to cycle through them--we had maps for non-semantic data tags, and this extends it

<ivan> @id Maps

gkellogg: similarly, type maps, which lets you index by type

<ivan> Nested property

gkellogg: nested properties--there are a number of JSON serializations that like to group properties under a non-semantic term
... This also allows for several indefinite recursion by fallout of the design

<ivan> scoped contexts

gkellogg: scoped contexts actually solved a number of different problems
... it allows you to define a context within a term definition, so the processor will apply the embedded context on top of the context already there

<ivan> scope for @type

gkellogg: scoped contexts can also be used for type values, and they can also be used for objects with multiple types
... and if any are used, that scope is applied
... that addresses the primary features added by the community group
... you can look at the changes for a more comprehensive list.

<gkellogg> https://github.com/w3c/json-ld-syntax/pull/2

gkellogg: these versions of the documents were described in the charter as the basis of this
... there are pull requests that the working group should consider, that would pull in the update from the community group that makes it a draft for the working group
... there are similar pull requests for the other documents
... there is the nice feature that will create a preview of the documents and the diff, against the 1.0 spec, though it might not be useful given the number of changes

azaroth: worth going through the algorithm and framing changes? is there a summary around that?

<gkellogg> https://www.w3.org/2018/jsonld-cg-reports/json-ld-api/#changes-since-1-0-recommendation-of-16-january-2014

gkellogg: there are also changes in the API document
... the primary one is to separate the processing from JSON-specific to web-idle (sp?), which allows this specification to be used for alternative serializations such as YAML.
... you can see where it's been highlighted to be changed for 1.1, it didn't need a whole re-write, just additional steps
... there is support for addl. keys, to support the various features that we use, such as container having different values, prefixes explicit
... I'm going to digress--there is an incompatible change from 1.0--a processor running in 1.1--in term selection, when finding a prefix for a compact iris, it adheres to the intention of the 1.0 spec
... in 1.0, any term could be used for a prefix--if you had to find a terms for sports, but you had a term for sports_events

<azaroth> e.g. http://schema.org/sports and http://schema.org/sportsEvent --> sports:Event :(

gkellogg: so there's a change to only map the term to an iri, or in 1.1 a prefix key, which allows it to be explicitly used as a prefix
... there's probably too much to go into in that much detail, but there are some changes to the API section, that rely upon portions of the alg. implemented rather than the core alg. itelse
... there is a problem that we may run into
... the error codes that are defined in 9.4.2
... are phrases, and apparently web-idle wants them to be single words

<azaroth> https://www.w3.org/2018/jsonld-cg-reports/json-ld-api/#jsonlderrorcode

gkellogg: so currently there is a RESPEC bug that when we cook this doc doesn't create IRIs for them
... we may want to change these error codes, though that would be an incompatibility

azaroth: any questions about the syntax or the APIs or algorhyms?
... less discussion, and more understanding questions?

ajs6f: small question--what is web-idle?

<leonardr> WebIDL

<bigbluehat> https://heycam.github.io/webidl/

gkellogg: it's a specification--interface definition language
... the idea being that you could run a tool that would translate that into the actual interface def. in whatever language you want.
... works well for javascript, but not other languages

<bigbluehat> WebIDL Level 1 Recommendation https://www.w3.org/TR/WebIDL-1/

gkellogg: in particular, it allows us to describe promise interfaces
... (async interfaces)
... so if you look at the expand/compact/flatten interfaces, you can seem them defined
... webIDL lets us find these sorts of interfaces
... the only way that we have to signal an exceptional condition, causes a promise to fail, which raises an error
... otherwise, the alg. are defined to be written in a purer form that does not require any specific interface requirements

azaroth: any questions about anything?
... let's go on to framing

<gkellogg> https://www.w3.org/2018/jsonld-cg-reports/json-ld-framing/

gkellogg: framing doc is somewhat different, as framing was never defined as a spec.
... work was done, but it was not complete, and it was not of interest to 1.1, however it is widely implemented and people are dependent on it.
... framing was intended to be use if you have a flat representation--RDF to JSON-LD
... you'd get many objects defined at the top level, which is not how people tend to look at these things.
... JSON-LD allows you to have similar embedding rules--but how do you get from a flat representation to a embedded representation
... framing creates a programming by example, you create a schematic document, that can be matched on different terms
... if you have a document that has a specific term, it will match on the type
... if that framed object contains values, framing will then look for objects that have those values
... so we can get back to the types of values that we type to see
... it can also be viewed as a query language
... but 1.0 matching was somewhat constrained, but there was a lot of work to do on wildcards, literal values with language, things such as that.
... 1.0 framing did not support named graphs, 1.1 does, either having the top level be the union or all graphs

<gkellogg> https://www.w3.org/2018/jsonld-cg-reports/json-ld-framing/#changes-since-1-0-draft-of-30-august-2012

gkellogg: ther are changes since the 1.0 draft, but they are based on the document published along.

timCole: Gregg, the community group has done great work
... in regard to framing, we did some early work with compacting, framing, and for moderately large docs it seemed framing, while powerful, was very slow.
... do we need to think about moving that into a recommendation, normalizing it, that the implementations be some real performance issues?
... or do we just worry about the spec, and not care about performance?
... the performance cost of that

ivan: from the process w3, the CR phase, the implement checking phase, the recommendation is complete and consistent
... which also means that there are no speed requirements by w3. We may decide to enforce that, but it would not be a requirement.

timCole: what has been the recent experience:

gkellogg: there's the larger issue of performance of JSON-LD for large values.
... It can be used for a dump format. A document with millions of records in it. The alg. as defined are not kind for this.
... you get into the combanatorial problem--it can be used for querying, but it's not written to take advantage of fast algorithms.
... the specs do not require that the alg. precisely, but operate in a way consistent with them.
... for instance, they're perscriptive around bnodes, so you must directly implement them
... personally, I think that there's other mechanisms that rely on graph querying where framing is specified much more like the construct from SPARQL, and it's not required that we do that, but we should provide some level of expectations around that.
... and the preponderance of those docs, say schema.org, webpages, it's probably perfectly adequate, but you get into cases when there are thousands of objects involved.

leonard: this seems to be an approach like XSLT for JSON

gkellogg: it's similar to that

bigbluehat: Gregg--can you paint a quick picture of framing vs. SHACL or SHeX

gkellogg: they're used for matching RDF graphs, and there's a certain matching component to this, but the audiences are somewhat different
... SHeX can also be used for creating new docs, so it's quite similar.
... but they're RDF graph based, so not concerned with topology

azaroth: we should look at pull requests
... and approve them to be merged

<gkellogg> https://github.com/w3c/json-ld-syntax/pull/2

<simonstey> SHACL https://www.w3.org/TR/shacl-af/ can do that too using rules (not part of the Rec though)

<gkellogg> https://github.com/w3c/json-ld-api/pull/1

<gkellogg> https://github.com/w3c/json-ld-framing/pull/1

azaroth: no point in reading every line, but can you describe?

gkellogg: nominally, the WG is moving from the CG, so we need to change those documents to no longer mention CG, etc. These define versions of the documents for that. Pull requests to create as editors drafts versions of these documents for doing changes the group approves of

<ivan> Proposed: the three PR-s (see above) define versions of the document as WG ED-s, serving as a starting point for the WG

<gkellogg> +1

<bigbluehat> +1

<azaroth> +1

<timCole> +1

<dlehn> +1

<simonstey> +1

<ivan> +1

<leonardr> +1

azaroth: no normative changes, just changes to make the WG drafts.

<ivan> Proposed: the three PR-s (see above) define versions of the document as WG ED-s, serving as a starting point for the WG, hence merge them

<bigbluehat> +1

<simonstey> +1

<azaroth> +1

<ajs6f> +1

<leonardr> +1

<gkellogg> +1

<timCole> +1

<hsolbrig> +1

azaroth: this doesn't mean we ever need to publish these, but it gives us a starting point

RESOLUTION: the three PR-s (see above) define versions of the document as WG ED-s, serving as a starting point for the WG, hence merge them.

azaroth: thank you, and are there any other issues or questions?

<dlehn> I just noted a common copy & paste typo in all the prs

<azaroth> scribenick: azaroth

david_newbury: We were running CONSTRUCT queries that made an index of 200k objects. The major bottleneck was framing, the docs were 1000 lines or so. 500 ms or 1second process, but with 200k objects that was a lot of processing
... so for indexing style projects, the performance indications are very real

<scribe> scribenick: david_newbury

gkellogg: might be to much bike shedding, but maybe there's an alternative around querying...

ivan: just a remark: it might be bikesheding, but to make sure we know the (?) to see if the framing document will make it impossible to make optimizations. That might be vague, but
... the blank nodes part, for instance, specified how they are named--there are good reasons, but if that's the bottleneck we should rethink that.

gkellogg: I agree, but I want to make sure that the complexity vs. something more precise.
... it might be that a note that describes an alg., or something with more detail

azaroth: for next call, it would be great to go through some design principles so that we have well-understood methods to assess features
... to help manage complexity vs. functionality, etc.

ivan: question on process--when I read through the syntax doc, some errors, editorial, some not--should we create those issues, or should we wait until we know the process?

azaroth: just migrate issues, create new issues.
... thank you, and we'll meet next week at the same time.

- DRAFT -

JSON-LD Working Group Telco

29 Jun 2018

Attendees

Contents

approve minutes

TPAC info

next week telco

further introductions

overview of the CG documents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output