Niklas Lindström: When I implemented this recently, I noticed that if you can serialize a path to rdf:nil, we should do that by using syntactic sugar form, even if the property is rdf:rest.
Niklas Lindström: The only case where you wouldn't do that is if that list node is not well formed.
Niklas Lindström: For example, it's an IRI, has something that's not rdf:next, etc.
Gregg Kellogg: ... and everything before that?
Niklas Lindström: If you encounter such a node, and there is an rdf:rest property pointing to it that is not well formed, then we don't do anything about the rest.
Niklas Lindström: I don't think that we should be that eager to unravel a list. There could be places, such as in OpenAnnotation, we don't know if it would be sufficient, but we could describe the first node as an IRI and then the rest as a well-formed list.
Niklas Lindström: I don't see a reason for the rest of the list to be treated as a non-list when it is a list.
Niklas Lindström: I'm not sure about Turtle serializers in general, but the rdflib serializer is doing the same thing as ISSUE-277 proposal.
Niklas Lindström: So, we should align with that (and this is a bug fix)
Dave Longley: What are the conditions under which this sort of data appears? Does anyone create the data intentionally where they wouldn't want @list?
Dave Longley: Do they go with the OpenAnnotations use case?
Markus Lanthaler: what niklasl just described is what my algorithm update will do
Dave Longley: Is it best to just wrap up as much of the list, or the end of the list as we can?
Dave Longley: If something isn't well-formed, we don't use @list at all. Is that preferable over wrapping everything up in @list... I don't know. Could we list out the various cases under which we'd encounter data where the list is not well formed, that might help us make a quicker decision as to what should be done.
Gregg Kellogg: owl:unions aren't... they use lists, but they're not well-formed.
Gregg Kellogg: They have a type of owl:Class.
Niklas Lindström: I think the first member in the list is a owl:Class, but I've seen that in Turtle notation.
Gregg Kellogg: I think every element is owl:Class.
Dave Longley: If that's true, this algorithm wouldn't affect that in any way. It would see that every element in that list is not well-formed, so we can safely ignore that case.
Gregg Kellogg: I think the main use case is where there are properties on the first element in the list, or the list is the subject.
Dave Longley: In that case, we want people to see the @list keyword.
Gregg Kellogg: I can't imagine a reason where you could use @list - you could also support lists of lists...
Gregg Kellogg: you'd just have a blank node as an argument and have the rest spelled out as rdf:first and rdf:next
Dave Longley: That would be awkward, but it's no different than what we have now.
Gregg Kellogg: Markus, what's your updated algorithm to address this?
Markus Lanthaler: Yes, it does. It keeps blank nodes in list, then rdf:next (scribe missed)
Gregg Kellogg: It's worth doing this even w/ increased algorithmic complexity. This is a detail of the spec.
Gregg Kellogg: We do have normative language for list of lists exception, we might remove that.
Markus Lanthaler: s/rdf:next (scribe missed)/the blank node has an @list-array as value of rdf:rest which represents the inner list
Niklas Lindström: I don't think anyone would care if we got rid of list of lists.
Gregg Kellogg: The exception is only generated now during compaction, if a property has list coercion on it... I don't think we need to generate that exception. We could get the recursive list behavior you wanted by using the sugar syntax.
Markus Lanthaler: The reason we need to raise the exception, if you have a property that is a list, and you have another list, then you raise an exception.
Gregg Kellogg: if we did this, we wouldn't need to do that.
Gregg explains the technical implementation of why we wouldn't need to throw an list of lists exception.
Markus Lanthaler: The algorithm I'm going to commit later doesn't have any side-effects.
Niklas Lindström: I think incorporating it will solve ISSUE-277, we could see where we're at with list of lists. We may need a separate vote on that later on.
Manu Sporny: We should put a warning on this change, going into Candidate Rec.
PROPOSAL: Adopt Markus' algorithmic change to convert partial lists from RDF to JSON-LD.
Niklas Lindström: +1
Manu Sporny: +0.2
Gregg Kellogg: +1
Markus Lanthaler: +1
Vikash Agrawal: +1
Dave Longley: +1
RESOLUTION: Adopt Markus' algorithmic change to convert partial lists from RDF to JSON-LD.
Niklas Lindström: After this change, rdflib implementation will be very much aligned.
Topic: GSoC Update
Vikash Agrawal: So, I think I have concluded the website (considering the indentation and validation bugs) Now I am writing my contexts (I made some progress with problems here) so I am reading the spec again
Vikash Agrawal: This being said, if I am able to complete the Person any time soon, I dont think Places and events will be a big hurdle. I will submit in /contexts/Person-1.jsonld file structure
Vikash Agrawal: I wanted to talk about the status of mid-term eval, which is starting from Monday! Can you please throw some light over that as in Pass or fail or a definitely pass
Markus Lanthaler: vikash, there are still sites which haven't been converted to the new layout.. the last one I saw was /minutes
Vikash Agrawal: Thanks manu for allowing the discussion and mlnt nikalas too
Vikash Agrawal: mlnt, Can you please just let me know those, I will complete those, no worries on that..
Vikash Agrawal: there were few parts I dint touch.
Manu Sporny: so vikash, on his proposal, had stated that he would be further along with the JSON-LD creator tool than he currently is for his mid-term evaluation, but i'm fairly happy with the work he's gotten done, though it seems like he could have gotten more done for one reason or another, a fail would mean that he's out of the program and i think that the work he's done on the website is certainly good enough to keep him in the program so i think we should pass him [scribe assist by Dave Longley]
Manu Sporny: are there any other thoughts on his status in the group? [scribe assist by Dave Longley]
Markus Lanthaler: i'm having trouble keeping up with what he's doing, could we get more updates on the mailing list? [scribe assist by Dave Longley]
Manu Sporny: we could ask him to do weekly updates [scribe assist by Dave Longley]
Gregg Kellogg: i would like to see vikash achieve a higher-level of proficiency in JSON-LD, given the time he's spent he still shows a naive understanding so i'd like to see him do better with that [scribe assist by Dave Longley]
Vikash Agrawal: dlongley sure. but I think, I am able to provide updates weekly meeting, unfortunately I wasn't able to join in a few of those.
Gregg Kellogg: i'd also like to see better quality of code in what's submitted so we don't have to go back and forth as much [scribe assist by Dave Longley]
Vikash Agrawal: gkellogg, Those will be done
Manu Sporny: some of what vikash may be doing could be a cultural thing or a student thing to do a first pass and then get feedback, there's certainly a steep learning curve as a student and we expect more of him but at the same time he's tackling a timezone, cultural, and knowledge gap [scribe assist by Dave Longley]
Markus Lanthaler: vikash, I would really prefer updates via mail to the mailing list..
Manu Sporny: i think we want to see improvement from vikash in all aspects, but i think he should continue work, is that the consensus? [scribe assist by Dave Longley]
Vikash Agrawal: weekly updates Noted.
Dave Longley: [general consensus]
Vikash Agrawal: manu, Yup, I feel the very same. on my personal fronts I do see, I need to more with json-ld
Vikash Agrawal: but I also think, I am learning various thingsand utility too.
Manu Sporny: dlehn was saying he definitely want him to be writing more code since it's GSoC, so the rest of his time should be spent writing a good chunk of JS code [scribe assist by Dave Longley]
Dave Longley: Vikash, there's general consensus that you will pass the mid-term eval
Vikash Agrawal: Feels good and thanks. Woot.
Vikash Agrawal: Thank-You so much everyone, and with out you guys this would have been impossible
Topic: Review JSON-LD github issues ready to be closed
Manu Sporny: we've responded to robin berjon's comments as much as we could, some concerns we couldn't address with the spec at this point [scribe assist by Dave Longley]
Vikash Agrawal: makes sure, that he will make a fast pace and do weekly updates
Manu Sporny: some people feel that robin is misreading what the spec is trying to do, i think i dealt with all LC issues he has there [scribe assist by Dave Longley]
Manu Sporny: understanding the JSON-LD data model is now difficult to understand, with all the changes we've had recently things have become very difficult to understand, the spec is pretty unreadable so we need some editorial changes to fix that [scribe assist by Dave Longley]
Manu Sporny: i think we're done with the GLD WG feedback [scribe assist by Dave Longley]
Manu Sporny: let us know if anyone thinks differently [scribe assist by Dave Longley]
Manu Sporny: we'll close that in 24 hours if there are no complaints [scribe assist by Dave Longley]
Manu Sporny: we have some ongoing discussion with markus on what we should do with the @context array feature [scribe assist by Dave Longley]
Manu Sporny: i think we're ready to close David and Peter's review issue [scribe assist by Dave Longley]
Manu Sporny: any thoughts from the rest of the group on any of the two remaining issues? [scribe assist by Dave Longley]
Vikash Agrawal: Thank-You so much everyone, and with out you guys this would have been impossible
Niklas Lindström: Issue #245 is tricky - if we do not allow the data to pass in { "@context": '...' } - not supporting that would be okay
Niklas Lindström: I think that's fine... but wouldn't be a hard +1 still.
Niklas Lindström: If you want to access RDFa as JSON-LD, any sort of extra syntactic ritual to access schema.org data would be problematic for political reasons. People are concerned about Linked Data cruft. We shouldn't allow @context key in - must not have a @context keyword.
Markus Lanthaler: The playground has been working list this - allowing @context.
Markus Lanthaler: It would make it symmetric to the context parameter, if we disallowed it, it would be a special case.
Markus Lanthaler: we've been doing that since the beginning, grammar has supported that from the beginning, no reason to change that now.
Niklas Lindström: .. the symmetry argument does speak to me
Gregg Kellogg: I can see an argument for increasing flexibility, that would imply being able to pass an object in that has a @context.
Gregg Kellogg: I think we should support as many different things being passed in that make sense, if we can do it deterministically.
Gregg Kellogg: Part of me doesn't like that it's so variable... but not supporting things where it's clear what the intent is, is bad.
Dave Longley: I support both, agree with Gregg.
Niklas Lindström: Yeah, I do the same.
Niklas Lindström: If you put an object in there that doesn't have a @context at the top-level, it'll be an issue.
Gregg Kellogg: I don't know if various options are specified, so we should detail this in the spec.
PROPOSAL: Make it clear in the specification that objects can be provided to the context parameter can either be JSON-LD Contexts, or objects containing JSON-LD Contexts.
Gregg Kellogg: +1
Dave Longley: +1
Manu Sporny: +1
Vikash Agrawal: +1
David I. Lehn: +1
Niklas Lindström: +0.9
RESOLUTION: Make it clear in the specification that objects can be provided to the context parameter can either be JSON-LD Contexts, or objects containing JSON-LD Contexts.
Markus Lanthaler: There is one minor thing that Gregg and I have been discussing about nodes with just @id when you frame.
Markus Lanthaler: Should such a node be in the output or not... that's one question.
Markus Lanthaler: The other one is that we should discuss whether we support +json media types in the API.
Markus Lanthaler: Currently, HTTP Link Header allows a publisher to link to a context w/o changing the document. That mechanism is specified to work just for application/ld+json
Markus Lanthaler: +json suffix has been standardized, application/stream+json should be able to use it as well.
Markus Lanthaler: The change would just be to re-phrase that section with a small explanation on what you invoke the API, to support all +json media types.
Markus Lanthaler: Look at the .compact() call... see how it says it's only applicable to application/ld+json? We could change that to "application/ld+json or "+json" suffix... we're overly restrictive here... we're just generalizing the solution. Different flavors of JSON, we should support them all.
Discussion about loosening restriction that application/ld+json documents MUST contain a @context keyword.
Dave Longley: This might be a recursion issue wrt. remote context.
Discussion about terminating when recursive HTTP requests are made against documents.
Niklas Lindström: We want systems to try to interpret things as JSON-LD if possible.
PROPOSAL: The JSON-LD API should process all documents labeled with media types using the application/json or any media type with a +json suffix. Implementations must not follow an HTTP Link Header if you encounter an application/ld+json media type.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: The JSON-LD API should process all documents labeled with media types using the application/json or any media type with a +json suffix. Implementations must not follow an HTTP Link Header if you encounter an application/ld+json media type.
Dave Longley: We're going to have to make algorithmic changes to certain things to support framing in the future, so it'll fall into the same bucket. It's not in the node map.
Dave Longley: Framing may need to make modifications to node-map and expansion to preserve things for framing.
Gregg Kellogg: We will need to provide a framing option to the algorithms.
Dave Longley: We already have to do that w/ other algorithms too.
Manu Sporny: Ok, so we're putting that discussion off.
Manu Sporny: ISSUE-264 - need to discuss
Dave Longley: we need to discuss recursion, when you use an HTTP Link Header, must you specify that the document is application/ld+json? The result is to avoid endless recursion.
Markus Lanthaler: That would simplify the problem quite.
Dave Longley: You might have a document that is application/json and it can't serve ld+json, so you need to have redirection for that.
Dave Longley: If we say you only follow one HTTP Link Header, you only have one result, plus you could support this use case. If you only follow one link header, it doesn't matter what the media type is.
Markus Lanthaler: That might be dangerous, it changes the interpretation of that document, in one case, you use the link header, in the other case you do not.
Markus Lanthaler: If you have a document that has an inline context, and that context depends on the remote context, you could have different contexts if you pay attention to the ld+json link header and one where you don't.
Markus Lanthaler: Talking about your proposal where you just follow one Link Header.
Dave Longley: Trying to figure out what you're saying... if you just follow one link header... (scribe missed)
Dave Longley: I'm fine w/ restricting to ld+json, if that's a problem, implementations will become looser.
Markus Lanthaler: It's always much easier to loosen something later, than restrict it later. I'd rather keep it stricter to start off.
PROPOSAL: A remote context MUST be served as application/ld+json.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
Dave Longley: +1
Niklas Lindström: +0.75
RESOLUTION: A remote context MUST be served as application/ld+json.
Dave Longley: Another issue here, when you get a remote context and you encounter re-directs, what becomes the base URL to resolve relative URLs against.
Dave Longley: In the case with w3id.org, do you use w3id.org/ as the base URL or the final destination.
Markus Lanthaler: Usually, with a redirect, you use the last URL.
Dave Longley: Is that true, or does it append onto the HTTP response code?
Markus Lanthaler: If you have a bookmark, the HTTP status states whether or not you should update your bookmark.
Dave Longley: One way to do this - if you're using a Link redirector, don't use relative IRIs.
Markus Lanthaler: or set the base.
Dave Longley: it would be strange to get back a document via redirects that has relative URLs and use a different URLs based on where you started from.