Gregg Kellogg: need to discuss availability for RDF WG F2F agenda
Markus Lanthaler: discuss article from Lin on need to have two different serializations of JSON-LD.
Gregg Kellogg: It's not unlike what Wikidata has to do.
Manu Sporny: I wonder if it's a limitation in JSON-LD or whether this has nothing to do with JSON-LD. Sounds like the latter.
Markus Lanthaler: I think it's really two use cases.
Topic: Wikidata visit
Gregg Kellogg: I went and visited about half a day Wikidata Germany. Spoke with several developers including Denny.
… In August, they sent out something about SWIG about their RDF serialization issues.
… Last message is August 9th.
… We discussed a little bit and it brought some issues.
… Brought us to an example with an item and its pronunciation. End up using two bnodes.
… Normally, that would be an RDF value but it doesn't seem to be particularly mainstream.
… Lowercase 'title' that would a language map and pronounciation and upper case 'TITLE' that would possibly have nodes on which they can hang data.
Manu Sporny: A bit strange
Gregg Kellogg: It is, but it helps with the API.
… JSON-LD gives you unique IDs for properties and context that gives you certain amount of typing, allowing you to distinguish between literals and objects.
… [example of Wikia and hybrid export]
… I probably need to write a blog post about that.
… JSON-LD is alive and well but not firmly established right now.
Manu Sporny: release schedule?
Gregg Kellogg: They have something right now. Schedule for real deploy end of March.
Niklas Lindström: First, quick reflexion. It seems that the Wiki idea of the upper case title property sounds like SKOS-XL structure
Niklas Lindström: I've done the same thing when I generated documentation from owl. My general reflexion, it sounded like what I've been doing in my own framing. I just wanted to note the similarities.
Manu Sporny: is there anything that this group should do? Anything they're waiting from us?
Gregg Kellogg: most important thing is to get to REC. Syntax is key to them more than the API at this point.
… Quite a lot of discussion, that was pretty good.
Manu Sporny: Good, thanks for the time you took to reach out to them.
Topic: RDF WG Face-to-face
Manu Sporny: I can definitely attend the F2F remotely.
Markus Lanthaler: I don't know much more, I just read that post where Lin basically outlines that they seem to need two different JSON-LD serializations.
… Data structure is different for each one.
… For one use case, given an article, the body of the article would be a bnode, and on the other hand, they want to model their data in a more "user-friendly" way.
Gregg Kellogg: there is actually a class for a Web page fragment in schema.org, which would be reasonable to use.
Manu Sporny: We should definitely continue to talk with Lin and see if there's something we can do.
Gregg Kellogg: From a modeling perspective, you might say that an article has a body and a description. Saying that it has a web page fragment kind of crosses domains.
… There are ways to do that, but that starts to be a little weird.
Markus Lanthaler: articleBody Text
Manu Sporny: anything we can discuss here in the absence of Lin?
Gregg Kellogg: Lin, we're discussing your dual-use of JSON-LD now
Lin Clark: oh, give me two minutes and I'll join
Markus Lanthaler: two issues raised, on negotiation between the 2 serializations and handling for RDF-ish domain models.
Niklas Lindström: I just want to make sure that I understand this. This is a general modeling problem, it doesn't seem to be an issue with JSON-LD, nor with RDF as an expression model.
… That's just a basic problem of "simple vs. complete".
… It's always a trade-off.
[Lin just joined the call]
Manu Sporny: Hi Lin, anything we could do to address these issues or are they best handled by the Drupal community?
Lin Clark: I honestly don't think that you need to change the spec for this.
… I'm pretty sure that this is something that we need to deal with internally.
Manu Sporny: Any comment on whether it should be a text string or an IRI?
Lin Clark: It does not matter too much for us.
Manu Sporny: I think I prefer to do an IRI, just because it's very specific.
Gregg Kellogg: +1
… You don't want two people to use the same string for different purposes.
Niklas Lindström: +1
François Daoust: +1
Manu Sporny: It sounds that we have general agreement for this.
Niklas Lindström: should it be "profile" or "context"?
Manu Sporny: Two different things in my view, the "context" points to a very specific JSON-LD context. The profile conveys the generic layout of the data. You may use multiple contexts but still one profile.
Gregg Kellogg: note there's nothing that prevents using a context IRI for the profile IRI
PROPOSAL: Add an optional parameter to the application/ld+json mimetype called 'profile' where the value associated with it SHOULD be an IRI.
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: +1
Lin Clark: +1
RESOLUTION: Add an optional parameter to the application/ld+json mimetype called 'profile' where the value associated with it SHOULD be an IRI.
Manu Sporny: Initial concern by Markus. Gregg suggested we made it very simple. The counter-argument to that is that it leaves some leeway in some compaction cases. I proposed to deal with it in rounds. I talked with Dave Longley about that, but that would end up with something that is actually more complicated than what we have now.
… The term ranking thing that we have seems to be the most reasonable thing for everyone in the end.
… We did talk about your algorithm, Markus. Dave Longley felt it was different but not necessarily simpler.
… In short, I think that where we are right now is: no reason to change anything as the only other proposal on the table does not bring a lot. Markus, what do you think?
Markus Lanthaler: I personally find my proposal simpler because you understand it when you write it on a sheet of paper and because I implemented it this way.
… The algorithm is already there but I did not really understand it so could not implement it.
Manu Sporny: That's my main concern. If one people in the group does not understand how to implement it, it does not start very well.
Markus Lanthaler: You can follow the steps and implement the algorithm. It just looks like code so you just won't understand how it's supposed to work.
Manu Sporny: Indeed, I don't disagree with any of the points you're making. I just think we have a time issue here.
… We should prepare a more prose version that we could put side by side with the algorithm in the code.
… It would take time though.
Niklas Lindström: There are some good examples in the comments. Is there a comprehensive set of tests for that?
Gregg Kellogg: Yes, there are. The problem is that tests often test for multiple things, so it may be hard to figure out what precisely is a problem.
Manu Sporny: That speaks more to "we need to fix the test suite".
Gregg Kellogg: If you implement things correctly, tests will pass and are great, but don't help you much when you fail.
… Perhaps what we could be doing is adding annotations to the spec.
Manu Sporny: your proposal would be to add issue marker to algorithms that are not clear enough?
Gregg Kellogg: Yes
Manu Sporny: And then we could go to Last Call.
Niklas Lindström: Manu, is your implementation currently using the algorithm in the spec?
Manu Sporny: Dave would know. I think so.
Markus Lanthaler: otherwise we wouldn't have one implementation.
François Daoust: I think that JSON-LD is in good shape regarding text and algorithms. I wouldn't worry too much about how the algorithm is defined, usually done after LC... that's what you do during CR. It's not such a big deal because we will need to refine the algorithms. [scribe assist by Manu Sporny]
François Daoust: We have done this before with W3C specs and it worked out just fine. [scribe assist by Manu Sporny]
Manu Sporny: let's mark the spec with an issue marker, saying that the algorithm might be refined for clarification purpose after last call.
Markus Lanthaler: I also have an implementation that passes all the tests. It may not be worth spending time adding issue tracking. Basically, I'm proposing to do nothing. We should check whether the current text passes the test suite.
… and update the text if it doesn't
Gregg Kellogg: or update the test suite.
… I'll go straight to where I'm failing and see if I can resolve those issues.
… If I can make mine pass or find something that we disagree about this week, that would help us for next call.
… Also, note that I don't think that we have tests for "flatten".
Manu Sporny: We should do that, although that should not block us from going to last call.
Gregg Kellogg: finding an online test runner was very effective for RDFa too.
Niklas Lindström: I note that I also prefer data to algorithms.
Manu Sporny: I think we're pretty much done with issues that could modify the spec dramatically.
… This one was on hold for other issues.
Markus Lanthaler: The grammar is too long so you can't get a quick overview of what's allowed where and what is not. I think it's 3 or 4 pages right now, it should be down to half a page.
Gregg Kellogg: I think that if you look at the text, the intention is to be very descriptive. It strives to be extremely precise of what could be happening without duplicating text.
… I would be satisfied if the introduction sections references sections that details them.
… That said, replacing with a short text is going to be very challenging, I think.
Manu Sporny: +1 to putting in references back to examples in the spec. +1 to it being difficult to distill it down to 1/2 to one page.
… [looking at node definition]
… I'm not convinced that making it smaller by removing that context is an improvement.
… Mostly, it's pretty much the examples that are sort of fluff.
Manu Sporny: Two statements from Gregg I agree with: 1. difficult to go down to one page. 2. to reference examples in the spec.
… I don't think we should be doing more than that. Removing examples should already give us what we need.
… Markus, if just those two changes are made (removing examples and pointing to them), would that be enough for you?
Markus Lanthaler: Yes, I think I'd be ok with that.
PROPOSAL: Move all examples in the JSON-LD Grammar section of the spec to the main body and point to them with links.
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: +1
[discussion about example IDs not generated by ReSpec for the time being]
RESOLUTION: Move all examples in the JSON-LD Grammar section of the spec to the main body and point to them with links.
Topic: Issue review
Manu Sporny: OK, let's make a really quick pass to remaining issues to see where we are.
… ISSUE-113: pending tests feedback as discussed today
… ISSUE-151: waiting on Dave Longley
… ISSUE-153: waiting on Dave Longley
… ISSUE-160: resolved
… ISSUE-140: deferred to JSON-LD Next (after some discussion at end of call today)
… ISSUE-162: need discussion
… ISSUE-156: need discussion as well
… ISSUE-125: done, I think. Where are we on that, Gregg?
Gregg Kellogg: I thought I had done that. Maybe Niklas could have a look to see where I'm clear/unclear.
Manu Sporny: Niklas, could you take an action to review that?
Niklas Lindström: Yes.
ACTION: Niklas to review spec text for ISSUE-125.
Manu Sporny: We have 3 issues that we need to discuss next week. Once those are resolved and text updates are made, we should be ready to go to Last Call.
Topic: Thoughts on .link()
Niklas Lindström: One thing I've been thinking about is whether we should take a stripped down version, a "connect" that doesn't do anything more than connecting IDs.
… If we wanted to include something like this in 1.0, we should probably do something simpler.
… If we put something in 1.0, basically, we should put an algorithm to produce an ID map.
Gregg Kellogg: we have one already
Niklas Lindström: Yes, so we could use it.
Manu Sporny: It's just to get a map of subjects to data.
Niklas Lindström: where is that algorithm used? Flattening?
Gregg Kellogg: Framing.
Manu Sporny: The one step generalization of what Niklas is proposing is a ".index" function that would index the data by the provided key.
… What the algorithm would do is flatten everything and search for the index property that you gave it.
… Just to be clear, this isn't "connect", it's "index".
… You would just get key-value pairs.
Gregg Kellogg: It just feels like creaping features in the spec at that stage.
Niklas Lindström: Perhaps the most reasonable thing to do is to continue working on it in a separate spec.
Gregg Kellogg: What makes these things a little bit experimental is when applied to expanded form.
… so there's value leaving it outside of the spec for the time being.
Niklas Lindström: One way to explain it is to say it turns JSON-LD Data into objects that are backed by an RDF graph and it makes leveraging that structure to manipulate data easily.
Manu Sporny: From what I hear, we have use cases but are not going to put it into 1.0 spec.
Niklas Lindström: I just found a test that uses @vocab with a notion of data that has not ID. Since there is no context, it's resolved against the vocal.
… I wonder if it's the right behavior.
Gregg Kellogg: no other interpretation where it would make sense, or it wouldn't expand to an IRI.
[discussion about @id: null, the spec tells the processor to ignore it]