Manu Sporny: I moved this to the JSON-LD.next milestone.. which means we are not going to include it in 1.0
... but since I did that Niklas wrote up a proposal
... my big concern is that we are pushing 1.0 back for 1-2 months if we are going to include this
... I would suggest to work on this in parallel and see if we can get this done before we go to LC, if we do, then include it. If not, then defer it.
Markus Lanthaler: I have a strong opinion about removing .connect() and .frame() - we have .flatten() in there, but it requires you to iterate over every object. We need a way to get to a node based on ID. [scribe assist by Manu Sporny]
Markus Lanthaler: We could have something like @id containers - we might be able to express that node map as valid JSON-LD. We could expose the node map via a call. [scribe assist by Manu Sporny]
Gregg Kellogg: These issues are orthogonal - if you don't have a node-map, you need to construct your own. Not all systems work that way, though - if you're working w/ backbone, it expects an array and builds an index using those models. The .flatten() method does create this data, but you can't access it. If we had @id-maps, we could expose this data. [scribe assist by Manu Sporny]
Gregg Kellogg: I'm concerned about adding these extra features - we don't have to have everything as the W3C spec when we first come out... we can add these in supplemental specs published by the Community Group. [scribe assist by Manu Sporny]
Markus Lanthaler: still.. I find it a bit weird to have an API that doesn't include a way to access data directly if you don't know the exact shape of the data
Markus Lanthaler: It's a bit weird to have an API without a feature like this. [scribe assist by Manu Sporny]
Manu Sporny: true.. I have been thinking about this myself as well.. The question is how easy it is for people to write it themselves
... I have been writing that several times myself
... I'm just really concernced that this requires more time
Gregg Kellogg: I believe there's a certain amount of energy left in the group (at least in my case)..
... I'm not sure we should take on more work before 1.0
Markus Lanthaler: I'm fine with delaying the issue until we get all the other stuff done. Let's look at this issue again when we're done w/ everything else. [scribe assist by Manu Sporny]
Gregg Kellogg: If you're interested in this feature, add spec text, add tests, implement the feature - that'll move us further on this feature. [scribe assist by Manu Sporny]
Manu Sporny: True.. that would be the right way to do it
PROPOSAL: Table issue-140 for the time being, delay discussion until all other issues for JSON-LD 1.0 have been addressed.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Lin Clark: +0
RESOLUTION: Table issue-140 for the time being, delay discussion until all other issues for JSON-LD 1.0 have been addressed.
Manu Sporny: Basically everyone agrees that tagging where the data came from is unworkable
... this leaves us with Gregg's proposal.
... We might need some minor changes though: instead of having just node references we would have to copy the data
... because otherwise it would be difficult to get to the data
Gregg Kellogg: Does the data using property generators contain node definitions?
Lin Clark: Yes
Gregg Kellogg: The other question is what the interoperability requirements are
... what would happen if an application that just understand one of the vocabularies modifies the data?
Lin Clark: It would be nice to have but I think it is definitely not a requirement
... we would do that directly in compact form
Gregg Kellogg: I just feel we are conflating a couple of things for convenience
... e.g. things that could be done with owl:sameAs
Lin Clark: there have been proposals using different HTTP headers, query parameters etc.
... but I think that's not the right way to do it
Manu Sporny: Prop. generators have some downsides but I think esp. for mobile apps they are very valuable
Manu Sporny: Lin, is there something in the current proposal that doesn't address Drupal's requirements
Markus Lanthaler: The main difference between the proposal I put forward and Gregg put forward was separating the "main id" from "alternative ids" - a term can also expand to alternative IRIs, but in compaction you just ignore the "alternative IRIs" [scribe assist by Manu Sporny]
Markus Lanthaler: This would keep the algorithm quite trivial because the "alternate ids" would be removed in compaction. [scribe assist by Manu Sporny]
Markus Lanthaler: Downsides are - no removal of extra data in compaction. The reasoning behind it is that you have a main vocabulary that you're using - you can use a more generic vocabulary such as schema.org or foaf. [scribe assist by Manu Sporny]
Markus Lanthaler: It's more or less a simple addition to expansion. [scribe assist by Manu Sporny]
Manu Sporny: You also had an issue with the implied relationship between all IRIs in a property generator. [scribe assist by Manu Sporny]
Markus Lanthaler: Yes, they might think that they're owl:sameAs when they're not. [scribe assist by Manu Sporny]
Markus Lanthaler: The other issue is that developers might assume that both IRIs compact to the same term... but that only happens when there is data duplication. [scribe assist by Manu Sporny]
Manu Sporny: all that being said, we all have concerns with property generators but it addresses a real world problem
PROPOSAL: Adopt Gregg Kellogg's property generator algorithm when expanding/compacting with the following modifications; 1) use node definitions everywhere when expanding, 2) generate bnode IDs for all node definitions without an '@id', 3) use deep comparisons when eliminating node definitions during compaction.
Gregg Kellogg: +1
Manu Sporny: +1
Lin Clark: +1
Markus Lanthaler: -0
François Daoust: 0
Manu Sporny: dlongley: +1
David I. Lehn: +0
RESOLUTION: Adopt Gregg Kellogg's property generator algorithm when expanding/compacting with the following modifications; 1) use node definitions everywhere when expanding, 2) generate bnode IDs for all node definitions without an '@id', 3) use deep comparisons when eliminating node definitions during compaction.
Manu Sporny: we have another proposal based on this resolution [scribe assist by Manu Sporny]
PROPOSAL: Add warning language to the JSON-LD Syntax and API specs noting the most problematic issues when working with property generators.
Manu Sporny: +1
Gregg Kellogg: +1
François Daoust: +1
Lin Clark: +1
Markus Lanthaler: +1
RESOLUTION: Add warning language to the JSON-LD Syntax and API specs noting the most problematic issues when working with property generators.
Markus Lanthaler: Do we want to add a flag to disable property generators?
... we don't have to put this in the spec though
Gregg Kellogg: We could add a note
Markus Lanthaler: Let's add a note to the warning section of this feature
PROPOSAL: Add a non-normative note to tell implementers that their implementations may have a feature that allows all but one node definition created by a property generator to be collapsed into a node reference.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
François Daoust: +1
RESOLUTION: Add a non-normative note to tell implementers that their implementations may have a feature that allows all but one node definition created by a property generator to be collapsed into a node reference.
Manu Sporny: Markus raised an issue that we might need define some processing/memory limits to mitigate DoS attacks
Gregg Kellogg: That would have to be done at an operating system level, right?
Manu Sporny: Well, you could e.g. count the number of method calls, document size. How to implement it would be up to implementers.
... but I agree.. it varies wildly from language to language
Markus Lanthaler: I feel like we're doing too much here - it's difficult to understand where in the document it is. [scribe assist by Manu Sporny]
Markus Lanthaler: where the error is - I don't know if it's possible to have a generic error handler like this. We could just have STOP_ON_ERROR and IGNORE_ERROR. I'd like to see an implementation of this. I can't make a decision based on this proposal. [scribe assist by Manu Sporny]
Markus Lanthaler: Yeah, having an implementation would be helpful to understand whether this is nice in theory, but impractical in practice. [scribe assist by Manu Sporny]
ACTION: Dave Longley to do an implementation of the conformance issue feature.
Lin Clark: No opinion on how it is implemented.
Manu Sporny: Dave Longley might have an opinion on this proposal. [scribe assist by Manu Sporny]
Topic: ISSUE-159: Add specifying @language to expanded form
Manu Sporny: Gregg, what about allowing @language in compact form but using @langmap in expanded form instead
... the problem with precedence rules is that a developer needs to know them to work with the data, and it's hard to keep all of that in your head.
Gregg Kellogg: Yes, but then this feature would become useless
Markus Lanthaler: wasn't that the same argument we just had for prop. generators? We don't want to have metadata in the data?
Markus Lanthaler: what about this? {"en": 4} - expands to - { "@value": 4 }
Markus Lanthaler: That wouldn't be put in language map when compacting
Gregg Kellogg: I think think is possible in compact form: {"foaf:age": [{"en": 42}, {"de": 59}]}
Gregg Kellogg: which would expand to this, if we use @langmap: {"foaf:age": [{"@value": 42, "@langmap": "en"}, {"@value": 59, "@langmap": "de"}]}
Gregg Kellogg: or this: {"foaf:age": [{"en": "42"}, {"de": "59" }]}
Gregg Kellogg: would expand to this: {"foaf:age": [{"@value": "42", "@language": "en"}, {"@value": "59", "@language": "de"}]}
Markus Lanthaler: I'm not convinced that we should include @langmap - it's metadata, it looks like it's a hack. [scribe assist by Manu Sporny]
Gregg Kellogg: The only reason to have a hack is so we don't get to the case where we have both @type and @language. We're adding a keyword to support an anti-pattern. Maybe we should just throw a conformance error if somebody tries to use a langmap and expresses a number against it. [scribe assist by Manu Sporny]