Manu Sporny: any updates or changes to the agenda?
Gregg Kellogg: We need to go back over the resolved issues and make sure that we can close remaining open issues. Can we close them, or what further action should be taken to close them? Or are they obsolete?
Markus Lanthaler: Regarding the test suite - should we do the split of the test suite?
Manu Sporny: I'd rather keep that in the current website for now - keep them all in the same place.
Gregg Kellogg: We could use git submodules, but that gets annoying.
Markus Lanthaler: It takes a while to download the website.
Manu Sporny: We could update the php to package up the test suite and download it.
Niklas Lindström: I agree with Gregg - working with it online or working with it as a web app has been very beneficial. If I have to run tests locally, I want to be able to check in copies of the tests to the repo - so I agree with Gregg.
David I. Lehn: btw, if git is too slow, github has a zip you can download. may be faster?
David I. Lehn: It's on the main page - you can download it.
Niklas Lindström: It would be beneficial if it was just the manifest and the tests.
Manu Sporny: This is about changing how JSON-LD keywords work - redefining keywords.
Niklas Lindström: General problem I have is with rdf:type - as it is a regular relation. Not being able to re-define @type is fine with me, if you can create a regular keyword and map it forrdf:type.
Niklas Lindström: I do it in the third example in the issue. I don't really know if the algorithm supports this.
Niklas Lindström: If i need to control the way rdf:type is used in compact form, can I?
Markus Lanthaler: Currently in compaction/expansion, nothing would prevent you from doing the thing in your 3rd example.
Niklas Lindström: Would my definition of @type take precedence over @type.
Markus Lanthaler: If you have @type in your document and you expand it, it doesn't get expanded to rdf:type in your document - they don't collide.
Gregg Kellogg: @type without a ??? is just another property - there is no issue in JSON-LD, the issue comes in when you round-trip.
Niklas Lindström: I can live with that from a matching point of view - when I compact, what is going to happen? Can I always force rdf:type to always be a set?
Gregg Kellogg: If you define something like 'a', then it will work just like any other definition.
Niklas Lindström: In my first two examples - they emulate what @type does, right?
Gregg Kellogg: No, @type doesn't expand... whereas 'a' would.
Niklas Lindström: In the 3rd example, I used 'rdf:type' without using '@type'.
Discussion around 3rd example and round-tripping.
Manu Sporny: It seems like this usage patter is a little strange.
Gregg Kellogg: You can support this with a frame.
Gregg Kellogg: The other question here is why we treat @type differently from other properties?
Niklas Lindström: That's what I'm asking here.
Gregg Kellogg: It might be good to specify @type as another property - this might create issues for framing, where framing requires a particular pattern.
Niklas Lindström: Someone on-list asked for something to this effect.
Niklas Lindström: We could solve this, but would have to be careful about not complicating things.
Niklas Lindström: If someone defines another term for rdf:type, then it should be treated like any other property.
Gregg Kellogg: That's too much special magic - we either demote @type to be just like any property, or you use framing.
Niklas Lindström: We have special casing for @type already, it's just where to put it.
Markus Lanthaler: If you look at this from a JSON perspective, it's the other way around.
Niklas Lindström: If you look at it from a Linked Data perspective, @type represents a link - and you can have that as a subject, you can have multiple types, etc.
Niklas Lindström: Unlike other relations, you can't say that you'd always want it as a set container. If we want to change @type back to a property, we may want to move things back from @type to @datatype
Gregg Kellogg: @type means two things, based on where it is used - if it's @type it might be in a value, it might be in array form, in other cases, it might not be in array form. If we went back to @datatype, we wouldn't have to complicate the code.
Gregg Kellogg: If we make @type in objects be like other properties, it would reduce complexity.
Manu Sporny: So the pseudo-proposal is re-introduce @datatype.
Gregg Kellogg: yes, that would reduce code complexity - but we should ask Dave Longley about this first.
Markus Lanthaler: Why do we have @type at all then?
Manu Sporny: Syntactic sugar that folks have come to expect... easier to write code based off of it.
Markus Lanthaler: How is re-introducing @datatype different from what we have now?
Gregg Kellogg: You can't override @datatype like you can override @type.
Niklas Lindström: Even in JSON Schema, there is a different between datatype given and relation to an object type.
Niklas Lindström: Even with JSON schema, which has nothing to do with RDF, there is a distinction.
Niklas Lindström: .. in json-schema: format is defined as "This property defines the type of data, content type, or microformat to be expected in the instance property values"
Postponing decision on ISSUE-91 - topics that we need to address: 1) if we want to reintroduce @datatype, 2) if keywords can be redefined, 3) if there is an initial context that specifies '@type' as syntactic sugar (@type is just like any other property)
Topic: ISSUE-92: Limit JSON-LD properties to one @list per property
Manu Sporny: A property can have at most one @list associated with it, that's what we're discussing here - due to complexity for supporting more - throw an exception if more than one @list is used.
Gregg Kellogg: I agree with that, there is another issue.
Gregg Kellogg: If there is a property that has @list coercion in it, then something in array form may need to be put into a list - we need to be consistent.
Gregg Kellogg: The main thing is what is the representation of @list in expanded form?
Gregg Kellogg: Can a property have more than one @list in it.
Gregg Kellogg: What is the expression in expanded form?
Gregg Kellogg: We have a pattern that is different from everything else we expand - if we show it in array form, it implies that we can have more than one element - clear that there can only be one list. It's an exception for the way values are treated in expanded form - additional complexity in processing algorithms.
Gregg Kellogg: You might have multiple properties that might expand to the same IRI, when you go to merge the arrays, it creates confusion on list order - two different lists or multiple values in the same list?
Gregg Kellogg: This is an issue in expansion.
Markus Lanthaler: In expansion, it is just 3 separate lists, right?
Gregg Kellogg: There are cases where you may have conflation - it may be 3 separate lists, or it may be one list.
Gregg Kellogg: I don't see a use case that requires more than one list in most cases - if you take that as a concern, then the representation is a single object - I'd rather see it as an array that holds a single object, not just a single object.
Gregg Kellogg: I don't think we want to go into the discussion on supporting multiple lists of lists unless there is a compelling use case.
Gregg Kellogg: Lists containing lists is extremely complicated.
Niklas Lindström: I think I agree from a practical point of view - one very strange real-world use case ^^^
Niklas Lindström: Really don't expect that to be used in JSON-LD. We should know that there is at least one case, and we should throw an exception in that case.
Markus Lanthaler: Could we split this into sub-issues - one for compaction, one for expansion.
Manu Sporny: I wonder if we should push this decision off.
Gregg Kellogg: We should be able to discuss how expanded form should look.
PROPOSAL: When performing expansion properties that are coerced to a @container type of @list MUST be placed in an array in expanded form. For example, "prop-iri"
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: When performing expansion properties that are coerced to a @container type of @list MUST be placed in an array in expanded form. For example, "prop-iri": [{"@list": [1, 2]}] is correct, "prop-iri": {"@list": [1, 2]} is not.
Gregg Kellogg: This was creating more corner-cases for us.
Gregg Kellogg: This will simplify the algorithm.
Markus Lanthaler: Maybe dlongley could add explicit examples.
Manu Sporny: Markus raises four questions - 1) Can multiple aliases exist for a keyword? 2) Why is aliasing of @context disallowed? 3) Are aliased keywords supported within a context? 4) How is this processed during contextprocessing/expansion/ compaction
Manu Sporny: I think we should allow multiple aliases for a keyword, don't know for #2, I think we only support aliases being used outside the context, defer to Gregg and Longley on #4
Markus Lanthaler: I agree with Dave and Gregg after discussion with them.
PROPOSAL: JSON-LD supports multiple aliases for a JSON-LD keyword.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: JSON-LD supports multiple aliases for a JSON-LD keyword.
PROPOSAL: Re-affirm that the aliasing of @context is disallowed due to algorithmic complexity/ambiguity and lack of a compelling use case.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
RESOLUTION: Re-affirm that the aliasing of @context is disallowed due to algorithmic complexity/ambiguity and lack of a compelling use case.
PROPOSAL: A @context is processed without regard to keyword aliases. Keyword aliases are taken into account when processing the body of a JSON-LD document.
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
RESOLUTION: A @context is processed without regard to keyword aliases. Keyword aliases are taken into account when processing the body of a JSON-LD document.
The group notes that the processing rules for compaction, expansion and framing are not affected by the previous 3 decisions.
Gregg Kellogg: I think that everyone agrees that the only time that @graph is dropped is when it is the only property expressed in a top-level object other than @context.
The current proposal is: If @graph is the only property in the document's top level object, it MUST be dropped in expansion and compaction. In all other cases (which includes @graph at the document's top level object when there are other properties at the same level), @graph MUST NOT be dropped in expansion and compaction.
Manu Sporny: I'm concerned about how the RDF WG will react to this - may be controversial.
Manu Sporny: This will affect normalization.
Gregg Kellogg: We need to be able to express graphs - Wikidata folks need this - we don't want to not solve that application because we haven't yet solved the graph issue.
Gregg Kellogg: this isn't a big complication to any of our algorithms
Gregg Kellogg: The interpretation when it comes to RDF is the tricky part - but I don't see it as that tricky
PROPOSAL: If @graph is the only property in the document's top level object, it MUST be dropped in expansion and compaction. In all other cases (which includes @graph at the document's top level object when there are other properties other than @context at the same level), @graph MUST NOT be dropped in expansion and compaction.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1 with a bit of faith
RESOLUTION: If @graph is the only property in the document's top level object, it MUST be dropped in expansion and compaction. In all other cases (which includes @graph at the document's top level object when there are other properties other than @context at the same level), @graph MUST NOT be dropped in expansion and compaction.
Manu Sporny: Those were all the discussions related to syntax, now on to API issues.
Topic: ISSUE-58: Specifying the active context for compaction
Manu Sporny: We are starting to have a great number of options for these API methods
Gregg Kellogg: We should probably put these in options.
Markus Lanthaler: What about mandatory arguments, like the context for compaction, or the base IRI?
Gregg Kellogg: We should discuss allowing passing IRIs or file objects to the compaction, expansion, etc. algorithms.
Manu Sporny: That's new, we'll have to discuss the signatures for these methods.
Manu Sporny: Should we focus the API on higher-level languages only?
Gregg Kellogg: I think so.
Discussion around arguments to API methods - whether there should be an 'option' object, or if mandatory options should be separate from 'options', such as the compacting context in the call to .compact().
Discussion concerning what the arguments can be for the input parameters.
PROPOSAL: The first input parameter for all JSON-LD API methods MAY be an object, an array of objects, or an IRI (DOMString).
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
RESOLUTION: The first input parameter for all JSON-LD API methods MAY be an object, an array of objects, or an IRI (DOMString).
PROPOSAL: The second input parameter to the .compact() method is the context that should be used for compaction. The value can be either an object or an IRI.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
RESOLUTION: The second input parameter to the .compact() method is the context that should be used for compaction. The value can be either an object or an IRI.
PROPOSAL: The second input parameter to the .frame() method is the frame that should be used for compaction. The value can be either an object or an IRI.
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
RESOLUTION: The second input parameter to the .frame() method is the frame that should be used for compaction. The value can be either an object or an IRI.
Topic: ISSUE-57: Should @context be minimized when compacting?
PROPOSAL: If the optimize flag is not set, the context used for compaction MUST be included without modifications in the resulting document. This applies to both context objects as well as contexts specified by passing an IRI. If the optimize flag is set, a processor is free to modify the context in order to optimize the resulting document body.
Markus Lanthaler: I think we all agree on this...
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
RESOLUTION: If the optimize flag is not set, the context used for compaction MUST be included without modifications in the resulting document. This applies to both context objects as well as contexts specified by passing an IRI. If the optimize flag is set, a processor is free to modify the context in order to optimize the resulting document body.
Topic: ISSUE-53: Remove normalization completely from JSON-LD API spec
Discussion about how this would be implemented across specification documents.
Gregg Kellogg: We don't need normalization in the JSON-LD API, it belongs in a normalization API.
Manu Sporny: So the 'normalization spec' should describe how to normalize RDF graphs and it should outline an API call to get back a list of quads that is normalized and sorted.
Manu Sporny: other issue is which bits to pull from the RDF API spec.
PROPOSAL: Remove the normalization algorithm and API from the JSON-LD API specification. The normalization algorithm will be placed into a separate RDF Graph Normalization specification which contains an API for retrieving a set of normalized statements.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
RESOLUTION: Remove the normalization algorithm and API from the JSON-LD API specification. The normalization algorithm will be placed into a separate RDF Graph Normalization specification which contains an API for retrieving a set of normalized statements.