The W3C JSON-LD Community Group

JSON-LD Syntax and API

Go Back

JSON-LD CG Telecon

Minutes for 2018-02-26

Agenda
https://lists.w3.org/Archives/Public/public-linked-json/2018Feb/0027.html
Topics
  1. Charter
  2. Pull Requests
  3. Issues
  4. #488 Properties can not be relative IRI
  5. #333 Support JSON values that aren’t mapped
  6. #491 define how to specify the json-ld profile in a request
  7. #547 Content addressable context
Resolutions
  1. forward charter to W3C Management for consideration
  2. accept PR #94 and #593
  3. adopt @vocab: @base gramar, and use RFC3986 resolution in this case.
  4. adopt solution defined in https://github.com/json-ld/json-ld.org/issues/333#issuecomment-366766394 as an interum solution, with final selection of the datatype to a future WG.
Organizer
Gregg Kellogg
Scribe
Benjamin Young
Present
Gregg Kellogg, Benjamin Young, Ivan Herman, Robert Sanderson, Niklas Lindström, Paolo Ciccarese, Ted Thibodeau Jr., Rob Trainer
Benjamin Young is scribing.

Topic: Charter

Gregg Kellogg: Charter document is at https:///json-ld.github.io/charter
PROPOSAL: forward charter to W3C Management for consideration
Ivan Herman: (Missed specifics on introduction to issue)
Ivan Herman: ...And it'd be good to have issues wrapped up as much as possible before voting ends
Ivan Herman: ...Technical issues can stay open, for the WG to address after it's official
Ivan Herman: ...But the chairs and staff will need to discuss specifics of the issues list
RESOLUTION: forward charter to W3C Management for consideration

Topic: Pull Requests

Gregg Kellogg: There are 3 open PRs that are under consideration
...2 are pretty straightforward
...unless someone wants to discuss these more now, I'm going to propose that we'll adopt them now
PROPOSAL: accept PR #594 and #593
Gregg Kellogg: +1
Robert Sanderson: +1
Ivan Herman: 0 (I have not looked at them:-(
Niklas Lindström: +1 (With caveat that I haven't really looked at 593)
Paolo Ciccarese: 0
Ted Thibodeau Jr.: +0
...Update the Expansion Algorithm to use an explicit _frame expansion_ flag
Fix compaction on scoped contexts based on @type
Benjamin Young: +1
RESOLUTION: accept PR #94 and #593
Gregg Kellogg: We can always look at these more in the future

Topic: Issues

Topic: #488 Properties can not be relative IRI

...TallTed is here to talk relative IRI resolution
Ted Thibodeau Jr.: The basic point is that we want to be able to use JSON-LD in the same way we use Turtle
...current the difference between the two formats handling of URIs is odd to say the least
...especially the difference between property and values
Gregg Kellogg: RDFa has a vocab attribute that works to make values relative
...perhaps niklas's memory on this would be helpful
...I believe we'd talked about relative URIs using concatenation rather than RFC3986's IRI resolution
...and there was concern of undesirable effects
Niklas Lindström: The confusion might be cleared up with the understanding that the value of keys is like pnames in turtle
...and the value space of @id is similar to the < > space in turtle
...with the caveat of the @type value...which maps to the short names of types in Turtle
...consequently I'm not sure I quite see the conflict
...if you don't use string concatenation, then you can't use anything ending in a #
...because it doesn't survive the relativization process
Ted Thibodeau Jr.: I can see that it doesn't have a zero basis
...but I fear the confusion will persist
...and not just for us
...I understand the arguments
...we'd like to express the same thing with a JSON-LD doc as a Turtle doc
...that's what we need
...and that relative URI is what we feel we need to do that
Gregg Kellogg: Ack: iherman
...that thing that makes it trivial to throw up a document without knowing the full URIs before you put it on the Web
Ivan Herman: Can you put an example where JSON-LD is different than Turtle
Niklas Lindström: I believe the examples are linked from issue #488
Gregg Kellogg: For example, <#relative>
Gregg Kellogg: I think it's relatively understood that it's defined relative to the document base
...and JSON-LD does not provide for that...well...it does, but in an unusual way
...you can define @vocab and define properties relative to that
Niklas Lindström: "Prop" {"@id": "some/path"} == :prop <some/path> != <prop> and <some/path>
...but there's no way to say that @vocab space is the same as document space
Gregg Kellogg: "@Vocab": "@base"
Niklas Lindström: The problem is that if you don't have a hash
...the link I just posed has 2 different JSON markups
Niklas Lindström: The problem is that if you don't have a hash/TallTed: the problem is that if you don't have a hash
...so if the solution is just to put in the @vocab of "empty"...
Gregg Kellogg: Well...that wouldn't work because it's not resolved relative to the document base when empty
...so we need some way of mapping @vocab to the document base
...which is why we've discussed @vocab: @base
Gregg Kellogg: Ack: gkellogg
Gregg Kellogg: My propose way of fixing this is to use @vocab: @base
...to tie the vocab space to the document space
...when that is done, then the IRI resolution switches from concatenation to IRI resolution from RFC3986
Gregg Kellogg: Ack: niklasl
Niklas Lindström: Well, it gets complicated with #'s doesn't it?
Gregg Kellogg: Well, in Kingsley's example he was using hash relative ones
...if it started with a hash, then it'd be fine
...if it ended with a hash, then you'd end up with 2 hashes
...however, if you used @vocab: @base, then it might replace the last hash component
Niklas Lindström: I don't quite see the use case
...it feels more academic than industrial
Ted Thibodeau Jr.: Well, since this is driven by an industrial need
Niklas Lindström: So in Turtle you do this now?
Ted Thibodeau Jr.: Yes.
Niklas Lindström: Do you have an example you can publish?
Ted Thibodeau Jr.: Not as such. but if you look at the pages we publish we have embedded Turtle, and we'd like JSON-LD islands also
...it forces use to know where the page will live prior to publication
...this is a little bit hand wavy, because it's not currently possible to do this
...but ideally, someone can author a page
...make some link data statements in various ways that are relative to that page
...and in the Turtle space this works fine and has for years
...but when we went to do this in JSON-LD, things got complicated
Niklas Lindström: K. I can see that. but I still don't see the criticality of it
...we really need to consider the implications of a change like this
...I think it's more author for an author to be explicity
...but it's just opinion and not fact
Ted Thibodeau Jr.: Well, consider you're authoring in an Intranet
...and using author storage space IRIs
...and when it comes time to publish, then all the embedded IRIs need updating
Gregg Kellogg: Ack: iherman
Ivan Herman: So. wearing my old semantic web hat
...I think it's a bad idea if Turtle's expressivity and JSON-LD expressivity differ
...I don't really care about RDF/XML...peace upon it
...but Turtle is the format of the Semantic Web community
...and JSON-LD can do well to learn from it
...I do think it's a problem if there are too many similar, but incompatible serializations of RDF
Gregg Kellogg: I think we can split my proposal into 2 parts
...@vocab: @base
...and separate from that is the way we construct IRIs using that
...it's equally confusing if we use 2 IRI resolution systems
...or conversely if we use string concat as with everywhere else
Ivan Herman: @Base is the document IRI if not redefined?
...like in Turtle?
Gregg Kellogg: Yes.
Ivan Herman: TallTed would that work as a solution?
Ted Thibodeau Jr.: I believe so, yes
Gregg Kellogg: As always the devil's in the details
...the bigger question is how @vocab: @base effects the IRI resolution
Ted Thibodeau Jr.: What are the options?
Gregg Kellogg: Currently, we resolve things against @vocab using string concatenation
...whereas, if you use RFC3986 resolution, dot sequences get resolved
...the last sequence of a hash gets replaced unless the IRI ends in a slash
Ivan Herman: Isn't it the same in Turtle
Niklas Lindström: For the <> space, yes, but not for prefixes
...so, for clarification, would it turn @type space into <> space?
Gregg Kellogg: Yeah. that's essentially the question
...now as an example of that, @type is different than pretty much anything else
PROPOSAL: adopt @vocab
Rob Trainer: While gkellogg is typing, I'm +1 to @vocab: @base and RFC3986 resolution
Gregg Kellogg: +1
...anything we can do to improve the clarity around how resolution will also help
Ted Thibodeau Jr.: +1
Niklas Lindström: +0.1 (I'm not sure about complexity, understanding and actual production value of it)
Ivan Herman: +1 (Provided we do not find too many devils in the details)
Benjamin Young: +1 (But I think defining the consequences is necessary)
Ivan Herman: So. +1 is for moving toward a PR, correct?
Paolo Ciccarese: +1
RESOLUTION: adopt @vocab: @base gramar, and use RFC3986 resolution in this case.
Gregg Kellogg: Yes. we'll need consensus on the PR

Topic: #333 Support JSON values that aren’t mapped

...onward. looks like we have 20 more minutes
...essentially, it would be nice to have a JSON-native data type
Ivan Herman: The equivalent of rdf:HTML or rdf:XML, right?
...for instance, if you were including GeoJSON, there's really no way to do that unless you're ignoring all of it or trying to interpret it all as JSON-LD
...so my proposal would be to expand the notation for @value
...so, @value could hold an object or an array
...something like "@value": [{"native": "json"}]
...which could be mapped via a context as {@context: "json-value": {"@type": "jsonld:JSON"}, "json-value": {"native": "json"}}
...given the need to define a datatype, we'll need to make this official as a WG, is that right iherman ?
Ivan Herman: Yes. we can explore it now, but to make it official, we'd have to do it normatively as part of a WG
...and possibly even within the rdf: namespace
Gregg Kellogg: Well...the existing rdf: is part of RDF concepts, isn't it?
Niklas Lindström: Rdf:XMLLiteral
Ivan Herman: Yeah. the details of making this happen are in the future, but it's not dissimilar to rdf:HTML and rdf:XMLLiteral
Gregg Kellogg: So I think we can probably proceed forward
Ivan Herman: To make it cleaner, we might put an explicit note that this is a temporary namespace URI and not the final one
...and it's expected to be updated
PROPOSAL: adopt solution defined in https
Ivan Herman: +1
Rob Trainer: Noting that pure JSON-LD that never expand things to triples, won't see this, correct?
Gregg Kellogg: Well... not exactly. the processor will need to know when to keep it and/or process it
Niklas Lindström: +1 (Detail: not just array and object, all of JSON preferably...)
...one way would be to @type: @json
Niklas Lindström: Yup...
Benjamin Young: +1 (To move toward exploring as a PR)
Gregg Kellogg: Any other thoughts?
Niklas Lindström: With the caveat that I think this should support all of JSON
Ted Thibodeau Jr.: +0
...numbers, booleans, etc.
...if you have a system that needs something raw as "just JSON" it needs to avoid tripping those processors up
Gregg Kellogg: Where this might run into issues is that everything ends up as an array when processed
...so it becomes impossible to know what's supposed to be a number intentionally and what would be separately stated to be a number
...we do something similar with @set
Niklas Lindström: It's going to be hard to understand I'm afraid
Ivan Herman: We do need to watch for complexity
...it is something we need to watch for as we move toward WG
RESOLUTION: adopt solution defined in https://github.com/json-ld/json-ld.org/issues/333#issuecomment-366766394 as an interum solution, with final selection of the datatype to a future WG.

Topic: #491 define how to specify the json-ld profile in a request

Gregg Kellogg: So. when I make a request of the server that I want to expressly have it framed
...similarly, how might I tell the server that I want it compacted
...anyone invested in this one?
...let's differ and ask again on a future call
...to see if the major supports show up to argue its case

Topic: #547 Content addressable context

Gregg Kellogg: This one covers how to deal in part with cross protocol issues, but also means of resolving contexts where an HTTP IRI may not be reliable for other reasons (caches, etc)
...there are many ideas explored in this issue
...as noted in the issue, the document loader already supports this by having it's own document cache
Gregg Kellogg: Ack: iherman
Ivan Herman: Why is this type of issue part of this type of specification?
...this starts to get into protocol design
...and perhaps not part of the language specification
Robert Sanderson: (Regrets, arrived at meeting that I was on the train for, and fell off voice)
Gregg Kellogg: We do use profiles for compacted, etc.
...and there are real life use cases for this like Verifiable Claims, etc.
Ivan Herman: K. well maybe its an editorial issue
...perhaps it's cleaner to separate everything that's HTTP related into a separate document
...it's a bit concerning to have the mixture of things in 2 places.
Gregg Kellogg: Ack: bigbluehat
Benjamin Young: I think we should defer this to another call, but it boils down to the lack of a promisorial nature of any URI that’s not matched to a content hash that includes it’s on validation, so that it can’t be used in a decentralized fashion. [scribe assist by Gregg Kellogg]
Gregg Kellogg: … There is no way that the URI will mean something today and not tomorrow. It may be a protocol issue. when you state as a publisher what I’m giving you, and we need something more promisorial.
Ivan Herman: In a sense, this reinforces what I said: it is a problem, but not for this working group. [scribe assist by Gregg Kellogg]
Benjamin Young: Maybe we just note in the document that are different IRIs that are more suitable. [scribe assist by Gregg Kellogg]