JSON-LD Working Group Telco — Minutes

Date: 2018-09-21

See also the Agenda and the IRC Log

Attendees

Present: Adam Soroka, Rob Sanderson, Gregg Kellogg, Jeff Mixter, David Newbury, Harold Solbrig, David Lehn, Benjamin Young

Regrets: Ivan Herman, Tim Cole, Simon Steyskal

Guests:

Chair: Rob Sanderson

Scribe(s): Adam Soroka

Content:

1. Scribe Selection

2. Approve minutes of previous call

Proposed resolution: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-14-json-ld (Rob Sanderson)

Adam Soroka: +1

Rob Sanderson: +1

Harold Solbrig: +1

Gregg Kellogg: +1

Jeff Mixter: +1

David Newbury: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-14-json-ld

3. Announcements / Reminders

4. Issues

4.1. Framing as a verb

Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/13

Rob Sanderson: OP notes that “framing” isn’t “surrounding with a structure”
… so why call it framing?
… but that ship has sailed: the term is in use

Benjamin Young: q about short names.
… “JSON-LD 1.1” is the name of one of our docs, version issues later might make that make no sense

Rob Sanderson: Short names must be approved by W3C mgmnt, because they serve as “namespaces”
… but working drafts do not
… changing the short name is more involved than creating a new version

Gregg Kellogg: it’s been called “JSON-LD Framing” from the beginning

Gregg Kellogg: wasn’t part of RDF 1.1, but has been known as “framing” since then
… dlehn may know more
… but the ship really has sailed

Proposed resolution: Too late to change the name at this stage, close framing#13 won’t fix. (Rob Sanderson)

Benjamin Young: +1

Rob Sanderson: +1

Gregg Kellogg: if this were new, maybe we could change names, but not now

Gregg Kellogg: +1

Harold Solbrig: +1

David I. Lehn: +1

Adam Soroka: +1

Jeff Mixter: +1

David Newbury: +1

Resolution #2: Too late to change the name at this stage, close framing#13 won’t fix.

4.2. subtitle for framing

Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/14

Gregg Kellogg: the subtitle of this doc is the name as I just described: “JSON-LD”
… it’s an extension to the API spec, but the subtitle doesn’t make that clear

Adam Soroka: +1

David Newbury: +1

Benjamin Young: +1

Harold Solbrig: +1

Rob Sanderson: +1

Jeff Mixter: +1

Gregg Kellogg: +1

David I. Lehn: +1

4.3. Remove bnode naming requirement

Rob Sanderson: link: https://github.com/w3c/json-ld-api/issues/25

Gregg Kellogg: creates some complications for testing, because you can’t use bnode labels
… expansion does not rename bnodes
… flattening does
… but you can use either normalization or isomorphism to compare
… but for a structural comparision we compare triples and expand to check lists
… so that would include bnode names
… so the only thing left is to flatten, turn into triples, and compare to see that the graphs are the same
… there was some discussion about using a bijection for comparison, but that made for a very complex test arrangement
… and we might not verify that the topology of the flattened doc is correct

Harold Solbrig: it concerns me to offer a bnode labelling algorithm– it might “leak”

Gregg Kellogg: https://json-ld.github.io/normalization/spec/

Gregg Kellogg: dataset normalization offers this
… because you have to be able to offer exactly the same quads

Harold Solbrig: would support making bnode labelling non-normative
… understand the problem with testing, but more worried about becoming a “standard” for bnode labelling

Gregg Kellogg: it’s already out there since 1.0
… so we might end up with a non-normative discussion instead

Rob Sanderson: how breaking a change is this?

David I. Lehn: as someone who may have to deal with the testing implementation, i’m somewhat unclear on what problems may come up with this

Rob Sanderson: will we be breaking 1.0 systems

Gregg Kellogg: depends on whether people depend on bnode names
… similar to bnodes for properties

Rob Sanderson: what would be the requirement after this?

Gregg Kellogg: thought it would be that bnode names must be unique and non-overlapping
… and if an algorithm can use our mapping, testing will be easier
… q is: can we eliminate it, or mark it as obsolete?

Benjamin Young: thinking from JSON perspective
… suppose someone is using the algorithms to go from JSON, what effect does this have?
… these effects could be shocking to a JSON user

Gregg Kellogg: these are unkowns
… smilar to what happens with most RDF parserse
… e.g. round trip from Turtle to NTriples, many people would expect bnode labels to be preserved
… but that’s not guaranteed, just convenient

Rob Sanderson: oooh, +1 to marking at risk

Gregg Kellogg: might mark this “at-risk” to get more feedback

David I. Lehn: wanted to ask what problems may come up with this

Gregg Kellogg: one type: people who rely on knowledge of the names generated
… which is just a really bad thing to do, but they might have done it

David I. Lehn: mostly my questions are how much pain this could cause for the test runner implementation ;)

Gregg Kellogg: then there’s ordering.
… part of the purpose of this algo is to preserve document order
… but if bnode names are different, could reorder output
… could use an unorder comparison for tests
… or could reduce each to triples and then again, normalization or compare by isomorphism

David I. Lehn: sounds like this will need an early set of tests just to test that the test runner comparison code works

Gregg Kellogg: would require more testing and discussion
… will be a pain for devs
… but devs could continue to use the informativ algos

Jeff Mixter: more of a philosophical apporach
… agree with “data-first” approach, think of bnodes as wildcards
… sad if devs have relied on naming
… but it’s the problem of parsing, not the data

Rob Sanderson: some might argue that we broke their nice little code
… if they’re sad, they can respond to the “at risk” status
… and if they don’t we go ahead

Gregg Kellogg: we can make this more visible in the next WD, with a blog post

Rob Sanderson: +1 to blog post on this

Jeff Mixter: +1 to post

Benjamin Young: +1 to blog post

David Newbury: +1

Proposed resolution: Mark normative blank node naming algorithm at risk in next WD plus blog post about this issue and obsolence of blank node as property ; if no feedback than proceed in subsequent WD (Rob Sanderson)

Gregg Kellogg: +1

David Newbury: +1

Rob Sanderson: +1

Harold Solbrig: +1

Jeff Mixter: +1

Benjamin Young: +1

David I. Lehn: +1

Adam Soroka: +1

Resolution #3: Mark normative blank node naming algorithm at risk in next WD plus blog post about this issue and obsolence of blank node as property ; if no feedback than proceed in subsequent WD

4.4. Base of an embedded JSON-LD block

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/23

Rob Sanderson: we don’t normatively spec the base URI for a JSON-LD block
… inside HTML
… could be several choices
… some of which could be further dependenet on other parts of the HTML doc
… the ticket has discussion for other problems with embedded JSON-LD, but let’s stick to base URI for this issue
… base is relatively clear

Gregg Kellogg: it’s the principle of least surprise
… if I load an HTML doc and it include JSON-LD w/ relative URIs
… they must be resolved
… make sense to use the doc base
… but what if I change the doc base using base head element
… used in RDFa
… would be odd if JSON-LD and RDFa in same page had diff base
… could be a pain, but it is what the DOM uses
… if we do something different, that would be even more surprising

Benjamin Young: all kinds of concerns about this
… about using data from non-Javascript mimetype surroundings
… yes, you can have all kinds of info about a script tag, but I wouldn’t expect it to change the text extracted from that script tag
… requiring interplay between the DOM and what’s in the script tag is a dangerous precedent and would have a lot of overhead
… would expect the base of the JSON-LD would be the same as if it were raw, sent by itself

David I. Lehn: while trying to generate framed json-ld which is not publshed
… and therefore have no base
… I’ve had to invent one to get the algos to work
… our docs seem to assume that the JSON-LD exists “at a location”

Benjamin Young: that affects Linked Data all over
… at WIley we do a lot of RDFa and JSON together
… we use a hash

David Newbury: I’ve been creating a base, even just “example.com”

Gregg Kellogg: has been an issue in the PLayground

Gregg Kellogg: https://tools.ietf.org/html/rfc3986#section-5.1

Gregg Kellogg: we want apps to have something to use
… in the absence of anything explicit
… if the mediatype is json-ld, we have a known way to establish a base with in the context
… but what about w/i a script tag
… we can say, it’s based on the URI that was used to retrieve the document
… there’s doc base, head base, and xml:base

Benjamin Young: https://www.w3.org/TR/html5/semantics-scripting.html#data-block

Benjamin Young: in that paragraph HTML5 says nothing around the script tag can have any effect on the stuff inside it
… we would break that
… would make a species of special JSON-LD style HTML parsers

Gregg Kellogg: 1=

Benjamin Young: moving the bar for consumption the wrong way– towards harder

Gregg Kellogg: excellent reference, can use that to solve this

Rob Sanderson: +1

Proposed resolution: When establishing the base URI, use the document base URL only and ignore all surrounding data such as xml:base (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Harold Solbrig: +1

David Newbury: +1

Adam Soroka: +1

Benjamin Young: +1

Harold Solbrig: +1

Rob Sanderson: e.g. if YAML came up with some internal way to change the base, this proposal would tell us to ignore that too

David I. Lehn: +1

Rob Sanderson: or any other serialization

Gregg Kellogg: not sure we can be that broad
… this reference is only good for this mediatype
… other mediatypes may have their own policies
… but in the absence of such specific guidance, we default to this stance from HTML5

Resolution #4: When establishing the base URI, use the document base URL only and ignore all surrounding data such as xml:base

Rob Sanderson: Also +1 to Gregg’s clarified clarification :D

Benjamin Young: but this is all within HTML5
… so that is the dictator we use as a conveyance
… but we’ve now nailed this to the wall succinctly

Rob Sanderson: we can reuse this guidance for language and text direction

Proposed resolution: Language, text direction and similar are not affected by surrounding content, such as attributes on containing HTML elements (Rob Sanderson)

Rob Sanderson: +1

Benjamin Young: +1

Adam Soroka: +1

Gregg Kellogg: the wording here is all negative
… we could instead say “only this way is correct”

Proposed resolution: The only thing inherited by the JSON-LD processor is the document location established by HTTP for determining the base URI, unless the rules of the embedding media type dictate otherwise (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

David I. Lehn: +1

Adam Soroka: +1

Benjamin Young: +1

Harold Solbrig: +1

Resolution #5: The only thing inherited by the JSON-LD processor is the document location established by HTTP for determining the base URI, unless the rules of the embedding media type dictate otherwise

5. Adjourn

6. Resolutions