JSON-LD Working Group Telco — Minutes

Date: 2018-10-05

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Adam Soroka, Simon Steyskal, Benjamin Young, Tim Cole, Gregg Kellogg, Ivan Herman, Jeff Mixter

Regrets:

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Tim Cole

Content:

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld

1. Minutes approval

Benjamin Young: any objections to the minutes as drafted?

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

Adam Soroka: +1

Rob Sanderson: +1

Tim Cole: +1

Benjamin Young: +1

Ivan Herman: +1

Simon Steyskal: +1

Resolution #1: Approve minutes of last call (https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-28-json-ld)

2. TPAC Reminder

Benjamin Young: Agenda in progress in Google Doc

Benjamin Young: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit#

Ivan Herman: most important item, there will be a list from organizers for evening dinners.
… conference center a little distance from center of town

Benjamin Young: there’s a spot in Google Doc for suggesting dinner location
… on Thursday

Ivan Herman: just to be sure everyone got it, I have created WebEx details for remote
… do not put the WebEx details out publicly

Rob Sanderson: I have reached out to Manu and Dan B., Manu is tied up, but suggested Dave Longley will be his proxy in json-ld 1.1 discussions
… Data Exchange WG has profile negotiation within their charter. We will talk that topic at 1:30 on Friday
… 3 or 4 reps from Data Exchange will join us for this discussion
… will ping Dan B. again
… are there other groups we should try to interface with?

Benjamin Young: Web of Things group? or maybe that’s more informal?

Ivan Herman: publishing WG is mo-tue, group is json-ld and schema.org for WP manifest
… could be a significant use case. So if any from this group want to / are available to join Publishing WG sessions, might be useful

Gregg Kellogg: Will likely spend time at Pub WG

3. Issues

Gregg Kellogg: Can we first get update on continuous publication?

Ivan Herman: it will be a token per document, and it’s on my calendar for Monday

Rob Sanderson: today we will revisit some issues previously discussed but still open

3.1. Infinite @reverse framing recursion (Gregg’s findings)

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

Gregg Kellogg: raises question about framing design criteria
… if there is no frame to be matched, algo constructs one
… so if you have something that infinitely recurses on @reverse, would mean a change to algo

Gregg Kellogg: https://github.com/w3c/json-ld-framing/issues/5#issuecomment-426846317

Gregg Kellogg: solution suggested in my latest comment is to use frame as really intended
… you would create necessary children finitely

Rob Sanderson: does this mean it works any differently for @reverse?

Gregg Kellogg: not really. In the absence of a property in the reverse it would create it.

Rob Sanderson: so if wanted to be explicit in the non-reverse direction you would just ???

Gregg Kellogg: no change, but describe behavior / example in primer

Rob Sanderson: questions?

Rob Sanderson: s/???/include them explicitly in the frame, the same as for @reverse/

Rob Sanderson: if not, how do we want to resolve? example in spec or note in primer?

Benjamin Young: willing to take a crack at what should go into primer

Adam Soroka: agree

Rob Sanderson: a note in the spec and then a longer discussion in primer?

Proposed resolution: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Benjamin Young: +1

Ivan Herman: +1

Tim Cole: +1

Adam Soroka: +1

Simon Steyskal: +1

Jeff Mixter: +1

Rob Sanderson: +1

Benjamin Young: +1

Resolution #2: Add a note to the framing spec about the asymmetry, and longer explanation with examples in the primer document for issue framing#5 on @reverse recursion

3.2. Fate of primer and related documents

Ivan Herman: related question - we are talking about the primer, but I’m a little concerned that it will become a bit of a dumping ground
… need someone to step up and actively take on the primer (and maybe someone else help Greg as editor of main specs)

Adam Soroka: possibility that one rule of thumb we could use, primer should be for people not familiar with json-ld, but may need a separate doc for real best practices

Ivan Herman: we can discuss at dinner at TPAC

Gregg Kellogg: there is a CG best practices that might serve as a starting point (or could be updated in place)

Benjamin Young: CG’s primer https://json-ld.org/primer/latest/

Benjamin Young: CG’s best practices https://json-ld.org/spec/latest/json-ld-api-best-practices/

Gregg Kellogg: for our primer, could we create a repo to make it easy to get started

Ivan Herman: I will do this and will add link from WG, but wait until we have someone who is going to take it own

Benjamin Young: we may want to migrate CG docs asap so we have somewhere to raise issues

Ivan Herman: agree setting up repo is easy, but do we need to wait for editors, etc. so we now exactly how many repos to create

Benjamin Young: https://github.com/w3c/json-ld-wg/issues/17 oh look! an issue related to this topic :)

Rob Sanderson: agree. Let’s put it on the agenda for next week. By time of TPAC we will then have a start

3.3. Do not compact to string (Rob’s new understanding)

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

Rob Sanderson: next issue, not compact urls to string
… raised in CG, suggested to use @id and @value to avoid this. @gkellog suggested @none.
… because @none would go in the context, you are simply saying that object has no type declared in context

Ivan Herman: the point is we do have this issue of using @type differently than how those of us from rdf world think of rdf:type
… we need to be very, very clear about this.

Gregg Kellogg: the way to think about @type is more like datatype
… really comes down to question of how different this concept is from original intent of @type (rdf:type)
… @type @id says treat as is URI, @type @none just says there is no datatype so you can’t compact down to a string
… when we expand, do we default to something or do we raise error?

Rob Sanderson: in the data @type is how you express rdf:type
… we need to make obvious the aliasing of @type to type and explain in the primer
… in terms of error vs. default when expanding, I would favor an error
… picking (guessing) seems dangerous

Adam Soroka: we can get into confusion about there is not a @type vs none

Gregg Kellogg: when you expand a document and type is not specified default is treat them as simple literals
… equivalent to saying default rdf:type is xsd:string

Rob Sanderson: "value": {"@type": "@none"}

Rob Sanderson: "value": "string"

Rob Sanderson: "value": {"@id": "rdf:value"}

Rob Sanderson: if we had @type @none for value then if in the data value : string, would be treated as a string

Gregg Kellogg: if in the context, would mean value is alias for string, if in data, either treated as error or treated as string

Rob Sanderson: {"@context": {"value1": {"@id": "rdf:value", "@type": "@none"}, "value2": {"@id": "rdf:value"}} …

Rob Sanderson: “value1”: “string”, “value2: “string”}

Rob Sanderson: for the above example, both would be understood the same

Gregg Kellogg: or value1 would generate an error

Benjamin Young: want to make sure rest of us aren’t just become spectators on this

Adam Soroka: so in response to @bigbluehat, let me offer my understanding
… so in rdf we distinguish between literals and strings

Simon Steyskal: -q

Adam Soroka: not the same in json-ld
… so in json-ld @type is doing several things at once
… so we keep adding more to what @type does, but it breaks down when moved into the rdf world
… so some uses of @type will add triples, some will not
… baked into the 2 different data models
… if you alias @type it aliases both for rdf:type and as datatype in the json-ld documents
… not good, but we are stuck with it, I think. So we need to document thoroughly

Rob Sanderson: seems 100% correct to me

Ivan Herman: yes, we are stuck with it, but nevertheless as a helping measure we could define a fixed alias and encouraging people to use alias differently
… down the line could become separate keys
… more than just a best practice, but also a temporizing solution

Gregg Kellogg: these issues came up in 1.0, but it’s good to mindful of the original json-ld which was find a way to understand your json as rdf
… so this is why we have context, and this is why we have to deal with URIs vs Strings
… we have discussed a default context (as a way to create default alias)
… does create an issue when compacting, because one of the aliases has to win out
… so round-tripping leads to these kinds of issues.
… we are restricted a bit on what we do for 1.1 (may be able to do more for 2.0)

Rob Sanderson: Thus {"@context": {"type": "@type", "@datatype": "@type"} ... } would allow people to use @datatype for data types, but compaction would always select one or the other for all situations

Rob Sanderson: so if we put aliases type and datatype, works for expansion, but would not roundtrip through compaction
… so maybe datatype has to more than just a context item

Gregg Kellogg: but it would break some compaction rules, so would require 1.1 being explicit

Rob Sanderson: are we ready to move forward? Or do we need more time

Ivan Herman: the latter

Jeff Mixter: I would like to mull this over more

Rob Sanderson: will make new issue about disambiguating different uses of @type
… will provide a framework for resolving issue

Gregg Kellogg: may take some time to resolve at f2f

Rob Sanderson: please add initial thoughts and then expect we may discuss in greater detail at f2f

Proposed resolution: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object (Rob Sanderson)

Tim Cole: +1

Rob Sanderson: +1

Benjamin Young: +1

Ivan Herman: +1

Gregg Kellogg: +1

Adam Soroka: If LD isn’t about making the +1

Jeff Mixter: +1

Adam Soroka: +1

Simon Steyskal: +1

Resolution #3: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object

4. Misc

Ivan Herman: next topic would be about embedded json (if we had time), this is a topic we need to discuss Dan B. and prioritize

Gregg Kellogg: can we see if he could be available for call?

Rob Sanderson: will try

Ivan Herman: but if he’s not available will need to wait until tpac

Benjamin Young: proposal suggested last week is consistent with what schema.org does, but need to know if its what they want

Ivan Herman: but what current tool does may not be relevant - seems like schema.org is working on major tool revision

Rob Sanderson: will also need to address blank node issue with Davel Longley (as proxy for Manu)

5. Resolutions