... the are a couple of comments that popped out as potential issues
Markus Lanthaler: I haven't been able to look at the changes that Dave Longley has made based on my comments. [scribe assist by Manu Sporny]
Markus Lanthaler: Dave's algorithms are more or less the same than I had in index.html, but overall, they're more or less the same. He uses an inverse context, looks like the one I wrote. Expansion looks fundamentally the same. [scribe assist by Manu Sporny]
Markus Lanthaler: Algorithms were moved around a bit, one algorithm got split (term definition / creation) from context processing, which I'm not sure if it makes sense. Gregg seemed to like it, so I'm fine w/ it. Personal preference, don't like jumping between algorithms. [scribe assist by Manu Sporny]
Markus Lanthaler: I found a few bugs w/ the algorithms, Dave has already fixed some of them. All of the bugs had to do w/ property generators and how they are processed. I think Dave tried to optimize some of the algorithms, but the optimizations didn't bring any advantage, they complicated the description, some bugs were introduced. [scribe assist by Manu Sporny]
Markus Lanthaler: So, some issues with property generator algorithms - if we want to keep the re-organization, then we need to decide. The algorithms are split out, moved around. It would make sense to keep things in that the same as before, would be my preference. [scribe assist by Manu Sporny]
Markus Lanthaler: Expansion is okay. Compaction, we might want to have a closer look. [scribe assist by Manu Sporny]
Markus Lanthaler: Flattening, node generation not changed so far... so good. [scribe assist by Manu Sporny]
Manu Sporny: Do you have a preference on which algorithms we should use? [scribe assist by Manu Sporny]
Markus Lanthaler: For expansion - we should pick Dave's. For compaction, we should pick mine. We need error code language, that's missing from Dave's spec, we have to agree on some language. [scribe assist by Manu Sporny]
Gregg Kellogg: I'm not entirely happy with splitting out the remote context processing
Gregg Kellogg: I've started to go through and do some implementation. My comments are mostly focused on the evaluation context at this point. I found the eval context processing pretty logical. Not entirely comfortable with splitting out remote context processing since Ruby is not an asynchronous implementation. [scribe assist by Manu Sporny]
... I would prefer to process it inline
... I think it was a premature optimization
... I prefer to keep context processing, IRI expansion/compaction etc. closely together
... there was a small comment that in some cases when you expand relative IRIs it might be in a remote context
... markus had a comment doing the shorter bits at the top of the algorithm instead of at the very end where it might get lost
... compaction: I found it easier to following the description dave was using for processing the inverse context
Manu Sporny: do you have a preference which spec text to take
Gregg Kellogg: my version was a try to do minimal changes.. I don't think that's going to happen.. the preference goes to using an inv. context
... I have to note that I have something similar than a inverse context
... but typically being too specific inhibits implementers creating differing implementations
... especially the naming of bnodes in the test suite might be problematic if you do things in different order (parallel)
Dave Longley: markus haven't seem my updates yet but I fixed most of the problems already
... so prop. generator stuff works now
... another problem was inheriting term definitions. I think what my new algorithm does is probably wrong
... markus had a test case choosing a term with a null-language
... question is whether choose the term with null-language or no language at all
... for numbers
... I think we need a quick discussion what should really happen
Gregg Kellogg: If it was a string I think you would want the null-language term
... I would go for the easier algorithm
Niklas Lindström: .. I consider 12.3 to be (syntactically) equivalent to {"@type": "xsd:double", "@value": "12.3"}
Manu Sporny: we use strings to represent very small numbers
... we don't want to have them to be language-tagged using the default language
... question is, should propertyNoLang or propertyLanguageNull be choosen?
Markus Lanthaler: quick question, if propertyLanguageNull wouldn't be there you would keep the complete IRI
Dave Longley: yes
Niklas Lindström: I think I would choose propertyLanguageNull because it's most specific, then fall back to propertyNoLang
Markus Lanthaler: I would be fine with that
Gregg Kellogg: yeah
Manu Sporny: ok, lets do that
Dave Longley: markus and gregg said we should highlight the removal of the context in expansion and not switching between contexts
Manu Sporny: Just to be clear - @language in the @context only applies to strings. For TC0048 output should pick the /more specific/ term definition 'propertyLanguageNull'.
... I think switching between contexts is the most common use case
Gregg Kellogg: expansions use is not just compaction.. you also need to expand when converting to RDF
Dave Longley: I think we can re-purpose expansion for RDF because RDF has no context
... I think it's confusing to say expansion just eliminates the context without saying why
Markus Lanthaler: Is it really simpler to switch between contexts than to say that the context is removed? [scribe assist by Manu Sporny]
Markus Lanthaler: When compacting, I apply a context to compact it again. [scribe assist by Manu Sporny]
Dave Longley: maybe a better way to reorganize it would be to add a section before expansion/compaction and describe it there
... and then just say expansion eliminates context, compaction adds one
Manu Sporny: does anyone thinks there are some fundamental problems in any of the current spec versions?
Dave Longley: I don't think so
... my preference would be to use alternate2 but pull in a bit more from what markus had
... we should also pull error constant
... we could also reorder some stuff
Gregg Kellogg: I think I support alternate2 as well
... I found the structure more accessible and especially the inverse context algorithm easier to understand
PROPOSAL: Base future JSON-LD Algorithms 1.0 specification work on Dave Longley's alternate2.html specification, keeping in mind that the group is not suggesting that all algorithms are finalized. Algorithms will need to be clarified further after the base document is picked.
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Markus Lanthaler: +0.5
Niklas Lindström: +1 (given my current partial knowledge, but I like the direction)
RESOLUTION: Base future JSON-LD Algorithms 1.0 specification work on Dave Longley's alternate2.html specification, keeping in mind that the group is not suggesting that all algorithms are finalized. Algorithms will need to be clarified further after the base document is picked.
Topic: ISSUE-213: Vulnerability when loading HTTP-based JSON-LD Contexts
Manu Sporny: we found a security vuln. in payswarm that you could reverse a transaction if a remote context was manipulated
... dns poisoning is the main problem
... proposal is to require remote context over https
... or to let the API define a hook which is then used to load remote contexts
Dave Longley: my implementation does that
Gregg Kellogg: I would be reluctant to require HTTPs
PROPOSAL: Add a JsonLdUrlDereferencer option to the JSON-LD API calls. It can be a function that takes a URL and a callback, and calls the callback with an error or the result of dereferencing that URL. If the option is provided, then the implementation MUST use it to dereference remote contexts.
Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +0.1
Niklas Lindström: +0.75
François Daoust: +0.1 (same arguments as Markus)
RESOLUTION: Add a JsonLdUrlDereferencer option to the JSON-LD API calls. It can be a function that takes a URL and a callback, and calls the callback with an error or the result of dereferencing that URL. If the option is provided, then the implementation MUST use it to dereference remote contexts.
Topic: ISSUE-204: Design Issue with Relative IRIs and compaction
Manu Sporny: The issue is that it requires us to use CURIEs at the RHS instead of terms
Manu Sporny: here are the options we discussed last time: 1) skips terms when doing the IRI compaction or 2) appends ./ to the name if it is an HTTP IRI or 3) exposes the risk that you may accidentally compact down to a term. [scribe assist by Manu Sporny]
Niklas Lindström: there 2 options
... if you use relative IRIs you should use ./
... when we auto-generate relative IRIs
... the danger is that people might use relative IRIs without "./" and their relative IRIs clash with a term
... e.g. "license": "licence".. would end up being a property linking to itself
... altough we don't like adding new keywords (and we had feature-freeze).. we might should add a keyword @url for type-coercions
... just uses relative/absolute IRIs
Manu Sporny: I don't understand why we need @url if we use "./"
Niklas Lindström: we don't need it.. but it would make it simpler for people to express their intent
Markus Lanthaler: If we are going to allow terms as values in @id, does it imply that @vocab is effective in @id? [scribe assist by Manu Sporny]
Markus Lanthaler: If we do that, then IRIs would be handled the same everywhere, which would be good. [scribe assist by Manu Sporny]
Dave Longley: Let's just use @vocab on the right, in @type and @id, and make it consistent everywhere. [scribe assist by Manu Sporny]
Gregg Kellogg: in RDFa we have different rules for subjects, properties, objects
... perhaps that doesn't make sense for JSON-LD
... but "./" just makes sense for hierarchical IRIs.. what about all other cases?
Markus Lanthaler: Maybe there is an argument here for just having relative and absolute IRIs in @id and @type... why is @type different? [scribe assist by Manu Sporny]
Gregg Kellogg: there are 4 cases in RDF where IRIs are used: subj, pred, obj, data type
... pred and data type it makes sense to be vocab relative, subj, obj should be document relative
Manu Sporny: that makes sense
... so @id wouldn't be vocab-relative
Manu Sporny: "foo": "PurchaseRequest"
... is the vocab. every gonna be used to expand something on the right hand side of a statement
... "@type": "PurchaseRequest"
Dave Longley: we could do something like @type: @vocab
Niklas Lindström: .. I still wonder if @type: @symbol wouldn't be more useful
Niklas Lindström: .. we need a keyword which says "expand terms and curies, or resolve against @vocab"
Dave Longley: @enum
Niklas Lindström: .. "license": {"@type": "@id"}
Markus Lanthaler: The minimal change we could make is to keep everything as it is currently, plus terms, but compact them to relative IRIs if they don't collide with a term. If it collides with a term, we just keep the full IRI. [scribe assist by Manu Sporny]
... what happens with this? "foo": "not-defined"
... discussing @type: @vocab
Markus Lanthaler: we should also probably just allow absolute iris in context
Dave Longley: @enum is an alternative, but a new keyword.
... proposal is to just allow absolute IRIs in the context, we introduce @type: @vocab, which would interpret values just as values of @type are currently processed
Manu Sporny: If "@type": "@vocab" is specified for a term in the active context, then processing for @id attempts to resolve as a term first, then a CURIE, then an absolute IRI, then a document-relative IRI. [scribe assist by Manu Sporny]
Gregg Kellogg: we could require @vocab to be defined in that case
Manu Sporny: If "@type": "@vocab" is specified for a term in the active context, then processing for the value associated with the term attempts to resolve it as an IRI - first processing it as a term, then a CURIE, then an absolute IRI, then against the active @vocab (if present), then a document-relative IRI. [scribe assist by Manu Sporny]
Niklas Lindström: not necessarily, you might just wanna use terms defined in the context
PROPOSAL: If "@type": "@vocab" is specified for a term in the active context, then processing for the value associated with the term attempts to resolve it as an IRI - first processing it as a term, then a CURIE, then an absolute IRI, then against the active @vocab (if present), then a document-relative IRI.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: Also, we can thus keep the resolution for Issue 204 (Do not allow terms as values for @id.)
Markus Lanthaler: yes, that's the point I think
RESOLUTION: If "@type": "@vocab" is specified for a term in the active context, then processing for the value associated with the term attempts to resolve it as an IRI - first processing it as a term, then a CURIE, then an absolute IRI, then against the active @vocab (if present), then a document-relative IRI.
Markus Lanthaler: value space of @id: compact IRI, absolute IRI, relative IRI
Dave Longley: {"@context": {foo: {"@id": "http://bar.org/1", "@type": "@vocab"}}, "http://bar.org/2": "foo"} expands to what?
Manu Sporny: value space of @type: @id: compact IRI, absolute IRI, relative IRI
Manu Sporny: value space of @type: @vocab: term, compact IRI, absolute IRI, @vocab, relative IRI
Niklas Lindström: yes
Gregg Kellogg: the difference of @type = @id and @type = @vocab is that @id isn't vocab-relative
Markus Lanthaler: yes, and terms are not used
PROPOSAL: The value space for terms tagged with "@type": "@id" is compact IRI, absolute IRI, relative IRI, the value space for "@type": "@vocab" is term, compact IRI, absolute IRI, @vocab, relative IRI.
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
François Daoust: +1
Manu Sporny: +1
RESOLUTION: The value space for terms tagged with "@type": "@id" is compact IRI, absolute IRI, relative IRI, the value space for "@type": "@vocab" is term, compact IRI, absolute IRI, @vocab, relative IRI.
Dave Longley: in compaction, if we have two terms just differing in @type.. what do we choose? @id or @vocab?
PROPOSAL: Within a term definition in the JSON-LD context, document-relative IRIs are not supported.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION: Within a term definition in the JSON-LD context, document-relative IRIs are not supported.
Markus Lanthaler: For the record, relative IRIs to reference external contexts are supported