Manu Sporny: Let's pick up at 5.10 Compaction Algorithm
Markus Lanthaler: should we use call time for this?
Manu Sporny: history shows that if we don't, it doesn't happen offline
Manu Sporny: most things are checked, we should be able to get through it in 30 minutes
Markus Lanthaler: the comment was if we need to describe how a shallow copy is made, as there is a lot of detail.
… Since properties can be added or deleteted, that shouldn't happen.
… Do we need to explain in such detail? Or, just say "create a shallow copy".
Dave Longley: people might implement it incorrectly. You can't just copy the properties and reference the array; it's actually two-level.
Manu Sporny: I think that's too vague. A "two-level shallow copy" raises more questions.
Gregg Kellogg: Perhaps we can say do a "two-level shallow copy"? [scribe assist by Manu Sporny]
Markus Lanthaler: I think most languages would also copy arrays
Dave Longley: I think just PHP does this, most other languages don't. Just the keys would be copied, and the arrays referenced.
Manu Sporny: 5.12 Inverse Context Creation Subalgorithm
Markus Lanthaler: similar point; in some steps it is also overly explicit in how to do things.
… As described, I wouldn't understand that it should be a pointer; we should be a bit more explicit that we mean a pointer.
… In this case, it's not a shallow copy.
Dave Longley: this happens a couple of places in the spec where we want to create a temporary variable. We also have the issue where gkellogg would like the algorithms to be described more "mathemetically".
… Not sure what language we should use. We might say "set to a reference of a member".
Markus Lanthaler: it would be enough to say "set variable to a reference of the value of key".
Dave Longley: we could say "reference the value of the key in the map", or "let this variable identify the value of the key in the map"
Manu Sporny: prefer the first form.
Dave Longley: "reference the value of the key in the map using the variable foo"
Markus Lanthaler: makes sense.
Markus Lanthaler: +1
Manu Sporny: Next up is step 3.3.6
Markus Lanthaler: this is purely editorial. Checks are all negative, it would be easier to be positive ("if there is a type mapping, rather than if there is not a type mapping")
Now on 5.11 IRI Compaction Algorithm
Manu Sporny: suggest dropping the “parent” parameter...
Manu Sporny: about dropping the parent parameter here, and in 5.13
Dave Longley: this exists so that you don't remove things.
Markus Lanthaler: the question is if you remove the duplicates in term selection or inside the compaction algorithm itself.
… Currently it's done in term selection, which also modifies data. I think it's cleaner to make term selection and IRI compaction to just return information, and leave modification to the compaction algorithm.
… The first one where all duplicates are found is picked, and duplicates are removed.
Dave Longley: my implementation doesn't remove data in term selection.
... There is a flag for removing things, which is set to false when called from term selection.
… The actual removal happens during compaction.
Markus Lanthaler: this means it loops over sub-trees twice.
… My selection is to not pass any data, but just return candidates.
… The final selection is done in compaction.
… If there are property generators, you get back potential property generators and a fallback term.
Dave Longley: this is less algorithmically correct, but seems odd that term-selection doesn't actually select a term.
Manu Sporny: it seems to me that term selection should give a single term.
Dave Longley: if you pass the parent, it can do the work for you.
Manu Sporny: I'm wary of putting the feature at risk because we've done the work.
Gregg Kellogg: JSON-LD is a better spec w/o property generators, we should mark them as at-risk. [scribe assist by Manu Sporny]
Niklas Lindström: the amount of work put into it is an indication of how complex it is.
Markus Lanthaler: implementing the algorithms doesn't mean that someone knows what's actually going on.
Gregg Kellogg: I'm concerned about removing such a big feature... we don't have a way of doing that if we remove the feature. [scribe assist by Manu Sporny]
Manu Sporny: we need the correct text if we're going to take it to LC. If it's going to be dropped, we can just stop discussion.
Manu Sporny: the timing is the thing.
… This would delay LC while we re-write the algorithms, after asking lin and scor.
Markus Lanthaler: perhaps just talk about things other than property generators?
Manu Sporny: 5.13 Term Selection Subalgorithm, second checkbox
Markus Lanthaler: dave used this to say if it is explicitly set to null or something else. I think it would be easier to just use @null.
Dave Longley: I think there was a test-case where the difference in language mattered; perhaps default language.
Markus Lanthaler: my algorithm is almost exactly the same, and I just use @null. I can't see where it would actually matter.
Dave Longley: if there were two terms, one used a null language, and the other didn't, you'd need to be sure you didn't loose that.
… It might be to simplify existence checks. We could change to check for existence of entries instead.
… I'll take a look at it and try to clean it up.
Markus Lanthaler: next comment is if variables should be different.
Manu Sporny: to address your concern about copy/paste into comments, they should add quotes to make sure it's clear.
Dave Longley: this was brought up by prototypo, I just want to be sure it's covered.
Manu Sporny: we could update ReSpec to add hidden back-ticks around variables, so that they show up when copy/pasting.
Gregg Kellogg: I'll look into supporting something that makes this simpler in ReSpec [scribe assist by Manu Sporny]
ACTION: Gregg to look at adding support in ReSpec for auto-quoting variable names in algorithms.
Next up: 5.14 Value Compaction
Dave Longley: I think it was a difference of opinion on what the style should be.
… One does a copy, the other doesn't and doesn't change things until it needs to.
Markus Lanthaler: let's just not discuss value compaction now.
Topic: JSON-LD Property Generators
Manu Sporny: it sounded like there was concensus to remove before LC.
… We should discuss with scor and lin, but the group would like to remove it due to the great complexity added.
Paul Kuykendall: how would this affect the actual RDF being created? Is it just a shortcut to not have to repeat yourself.
… I see that we have a use-case that could make use of this, for example, when building out ontologies so that we can merge.
Markus Lanthaler: use case has to do with transforming to RDF?
Paul Kuykendall: we're using JSON-LD more like JSON/RDF structure. We're generating some ontologies that define the business domain and trying to tie them to other existing ontologies (dc, schema, etc.).
… to allow customers better access into the data.
… For example, we have our own internal structure for "address", which has a lot of cominality, using sameProperty within the ontologies, that is expressed in the code.
… To say that these are the same thing.
… We to SPARQL inference in the client, and they then parse out what they need.
Dave Longley: is it read-only?
Paul Kuykendall: they can write back. It may be SPARQL Update in the future.
Gregg Kellogg: Well, the support you're showing for it might mean we have to keep this feature... even if we don't like it that much. [scribe assist by Manu Sporny]
Markus Lanthaler: you said you're defining ontologies, and mapping them to DC, Schema and so forth?
Paul Kuykendall: yes; However, the clients don't necessarily know about this mapping, as we can hide things behind the scene.
… If it turns out that they're really a bad idea, it's early enough in our cycle that we could change.
Markus Lanthaler: the only change, if we drop property generators, you would have to be explicit about having three different properties.
Paul Kuykendall: the concern is that you have data-duplication that it populates all of them and reduces the chanse of programmer error.
… Making sure that all copies are updated, rather than just one of three copies.
Markus Lanthaler: one of the problems with PG's is that if the client expands and only changes one of the values, it wouldn't compact back again.
Niklas Lindström: it is duplication, just hidden.
Paul Kuykendall: we use compacted form between client and server.
… If I had the incorrect notion, maybe we should take this out, so we don't have a mis-interpretation.
Dave Longley: there is nothing passed to tell how to re-compact, just the values need to be the same.
Paul Kuykendall: that sounds like a great reason to get rid of them, as it might be deceptively simple and create more problems later on.
Niklas Lindström: describes RDFa mechanism for vocabulary expansion.
Paul Kuykendall: My mis-understandings implies that other people might also be confused about property generators.
Manu Sporny: there is no easy solution to your use-case. The alternatives might actually be worse than property generators.
Markus Lanthaler: hi lin
Markus Lanthaler: we are currently discussing whether to drop property generators for 1.0
Dave Longley: either way, your application is going to have to keep track of what properties go together.
Manu Sporny: Wondering about possible future use of property-generators in Drupal.
Lin Clark: at this point, I don't think they're a requirement for us.
… We're focusing our use of JSON-LD to aligning ...
… We're not necessarily optimizing for smaller size, so it should be okay from our stand-point.
Manu Sporny: seems like paul has a use case, but PGs don't fully express it, and there is a fair chance of making things worse.
… Lin's use case has found a different solution.
… At this point, it doesn't seem we have anyone that really needs them.
Markus Lanthaler: easier to remove now and re-introduce later than the other way around.
Niklas Lindström: they border so much on semantics, that people can use things like vocabulary expansion to do the same thing. It's not syntactic, but semantically, it's already defined.
Dave Longley: I think the only way for them to work in the future if we allow updates would be to include something in expanded form, but for everyone converting to RDF, it wouldn't work.
… People would have to program to understand the special relationships between properties.
PROPOSAL: Remove Property Generators from JSON-LD before Last Call due to no developers needing the feature, the feature having a high potential of misuse, and because of the complexity it adds to the specification.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1
Niklas Lindström: +1
Paul Kuykendall: +1
RESOLUTION: Remove Property Generators from JSON-LD before Last Call due to no developers needing the feature, the feature having a high potential of misuse, and because of the complexity it adds to the specification.
Manu Sporny: a new feature requested, with a couple of implementations.
... Of course, we're well past feature-freeze, even if they seem simple to add.
Niklas Lindström: I've been using it since 2011, and at the National Library I come across it all the time.
… Today, we abstracted people for which there exist not descriptions, but we want to record the relationship anyway. For example createorOr. There are no such properties, so using ^creator allows us to express this.
… Not all vocabularies define inverse properties, and certain disciplines frown on explicitly defining inverses of properties.
… you naturally create things over time, you link a book to an author, and don't always update the author to link back to the book.
… I've felt needs for links to objects, such as RDF/SPARQL Constructur results, or CBD's, where I want to root the description in the primary object, and have things that link to/from this.
… Filter authors/works, and works/authors. In many expressions, it's useful to say the inversee.
Gregg Kellogg: Curious if you've implemented the round-tripping bits of this? [scribe assist by Manu Sporny]
… I haven't implemented round-tripping in the code I have so far. It's been a while, and I think I had something working in the past.
… It seemed fairly simple to do, as long as you don't define both to and from forms.
Markus Lanthaler: I implementier compaction, and it's quite triveal.
… (example provided.)
… children expands to parent.
… It also takes into consideration if there is @reverse in the data.
Niklas Lindström: this cleanly solves the two variants I had in the past, but this is cleaner.
… I'd like to see it as you've implemented it.
Paul Kuykendall: we also have some use cases we're using on where we need support for inverse relationships.
… We had to do a work around where we do inferencing on the client side to look for inverse relationships, so it can understand what properties to set.
… We do have a way around it, but this would be a nice to have feature.
… We have a (barley adequate) workaround, but we need something different.
Manu Sporny: would it be enough to create a description of how it works, not include in JSON-LD 1.0, but all implementations have the feature.
… Or, we have an implementation, and Markus could put his algorithm in there, but we run a risk of standardizing something that doesn't work for everyone.
Gregg Kellogg: I'm concerned that we might be putting this into the spec before it's ready. I have some other feature additions that might need further thought. Trying to solve everything at this point is a recipe for disaster. I think we need to embrace an "open specification" approach, and close the door on JSON-LD 1.0 Core in order to allow in order for people to start using it. [scribe assist by Manu Sporny]
Gregg Kellogg: We can start adding features after that... easier to put it in later than add it in now and possibly remove it later. [scribe assist by Manu Sporny]
Niklas Lindström: it isn't new from my perspective, and is a very natural feature when you express graphs as trees.
… We also have the BBC use, which is what brought this up.
Manu Sporny: would having it spec'd out elsewhere be enough?
… How many years before JSON-LD 1.1?
… If it's broadly implemented, it doesn't really matter if it's in the core spec.
Markus Lanthaler: other specs would not be compliant, as they must otherwise drop such properties or values.
… There are some special cases (no @id and @reverse), but it's about an afternoon to make it solid.
PROPOSAL: Put JSON-LD Inverse Properties into the JSON-LD 1.0 specification as an at-risk feature.
Manu Sporny: -0.6
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +0.2
Dave Longley: +0.5
Paul Kuykendall: +.5
RESOLUTION: Put JSON-LD Inverse Properties into the JSON-LD 1.0 specification as an at-risk feature.
Manu Sporny: since we have @base keyword, should we have something you can pass into the API?
… I think so, but @base always overrides this.
Markus Lanthaler: what is @base used for in JSON-LD? Is it also used for compaction?
PROPOSAL: 'base' (passed in via the API) sets the document base, @base (in the document) overrides any value set by 'base' (passed in via the API).
Gregg Kellogg: +1
Manu Sporny: +1
Paul Kuykendall: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: 'base' (passed in via the API) sets the document base, @base (in the document) overrides any value set by 'base' (passed in via the API).
Dave Longley: I think we should allow the empty string ("") be specified, so that you can say there is no base.
Gregg Kellogg: I use stuff like that to specify that things should be able to be expressed via relative IRIs... it makes the document work if it's served via any location. [scribe assist by Manu Sporny]
… this would allow for the use of IRIs, so you'd keep relative IRIs.
… (reverses scribe's understanding).
… If you use @base "" it means to not change them, relative IRIs come in and go back out, for example in @id.
Markus Lanthaler: What happens if you do this? '../test/.../hello' does it get compacted to this? '../hello' ? [scribe assist by Manu Sporny]
Dave Longley: should be no changes. If you specify @base: "", make no changes to IRIs on input.
… This does not rule out using terms and @id.
… My preference is to do no processing at all; a way of saying "don't touch my IDs"
Manu Sporny: I don't know how standard this is, how many other serializations say don't touch IRIs.
… Not doing path normalization might be a problem.
Markus Lanthaler: can we stay silent?
Manu Sporny: we need a test-case for it.
Niklas Lindström: .. "you can also pass an empty string and see what happens" ;)
Dave Longley: if we do this sort of normalization, it will impact normalization algorithms.
Markus Lanthaler: my read of the specs, is that paths would be resolved.
Dave Longley: we link to the spec, and say that.
Markus Lanthaler: process them as they're always processed in JSON-LD.
PROPOSAL: Allow @base to be set to the empty string. If @base is set to the empty string, relative IRIs are processed according to RFC 3986 Section 5.2.2 (which is how they're always processed in JSON-LD).
Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
Paul Kuykendall: +1
RESOLUTION: Allow @base to be set to the empty string. If @base is set to the empty string, relative IRIs are processed according to RFC 3986 Section 5.2.2 (which is how they're always processed in JSON-LD).
Manu Sporny: The diff-marked version for the live spec is always broken, you can try using the 'diffmark tool' in the live version of the spec.
Markus Lanthaler: Try doing this: CTRL+SHIFT+ALT+S then click on 'diffmark'
Paul Kuykendall: we're fixing our APIs to be closer to the latest spec, would be nice to know what changed.
Manu Sporny: You're probably going to have to save a local copy and run the 'htmldiff.pl' script between the version you used to implement and the current version (saved as a static file via CTRL-SHIFT-ALT-S).