Re: Multi-pass @context (ISSUE #41)

On Dec 1, 2011, at 7:19 AM, Markus Lanthaler wrote:

>> This requires two passes over @context, first to resolve prefixes, and
>> second to use those prefixes in @datatype declarations. Note that
>> before, when @coerce was a separate object, this processing was in
>> effect; it was lost when we folded in datatypes with prefix
>> definitions.
>> 
>> As a related issue, we could consdier the following:
>> 
>> @context: {
>>  "xsd": "http://www.w3.org/2001/XMLSchema#",
>>  "dc": "http://purl.org/dc/terms/",
>>  "date": {"@iri": "dc:date", "@datatype": "xsd:date"}
>> }
>> 
>> This adds another layer of complication, as it may require more than
>> two passes to resolve the use of CURIEs in @iri definitions, so I would
>> not go this far, although the use of a CURIE should be allowed, if it
>> is defined in an outer context.
> 
> I think that would create quite some confusion and inconsistencies as a
> prefix could be overwritten in the local context. The expansion algorithm
> would use the previous value for expanding @iri while the current value
> would be used for expanding @datatype.
> 
> That being said, the whole local context has to be in-memory anyway; it
> can't be processed on-the-fly as a stream. So I don't think we should spent
> to much thoughts on this. The only thing we should be aware of and that we
> should make clear in the spec is that cycles are possible and should be
> handled.

Well, you could have a dependency chain of term definitions, so it could be confusing as to how to do this, but that's a real corner-case. We'd need to say, first look for term definitions. Then, resolve any IRIs that don't depend on these term definitions using the active context. Subsequently, resolve term definitions that do have these dependencies (ignoring, for the moment, the pathological cascading dependency issue). Then resolve @datatype IRIs.

This was why I suggested not covering this case, but it's really an issue for processor implementers to worry about, not authors. Not too clean, though.

>> I believe that we should adopt the first form, as it is a natural way
>> to create a context for authors, and there is a reasonable possibility
>> that there will be errors if authors do not separate prefix definitions
>> from the usage in datatypes.
> 
> I would prefer the second form as it really eases the life of users while
> the algorithms aren't getting much more complex. I quickly hacked a demo in
> PHP [1] that can process prefix:suffixes in @iri and in @datatype.

This would be the most consistent, if the added complexity to the algorithm is acceptable.

> We also have to make clear that just a absolute/relative IRI and a
> prefix:suffix can be used but not a normal term as that would be interpreted
> as a relative IRI. Sometimes I really think it would be much easier if we
> would use the square bracket convention to denote CURIEs.
> 
> 
>> I propose that we formally say that context object traversal is a two-
>> pass operation, where first IRIs for defined terms are identified and
>> then @datatype and @list processing occurs, so that prefixes defined
>> within a context can be used for @datatype definitions.
> 
> Why do we have to say that formally? That's an implementation detail.

We need to describe an algorithm. In the context of that algorithm, it would be implicitly multi-pass.

>> As an alternative, we could define a set of terms that are defined in a
>> global "default" context, similar to RDFa's default context. There we
>> could define mappings for xsd, rdf, dc, foaf, schema and others. This
>> would eliminate most need for doing two-pass processing of contexts.
> 
> I have a really strong opinion of not doing this. It just makes things more
> complicated than they need to be. We can have a reference context defined
> somewhere at w3.org or json-ld.org that can be imported with those defaults
> but not hardcoded in the implementation.

Yes, of course, as RDFa does it. That was what I meant.

Gregg

> [1]
> https://github.com/lanthaler/JSON-LD-experiments/blob/master/context-coerce-
> merge.php
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Thursday, 1 December 2011 18:46:40 UTC