W3C home > Mailing lists > Public > public-linked-json@w3.org > December 2011

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 1 Dec 2011 23:19:31 +0800
To: "'Linked JSON'" <public-linked-json@w3.org>
Cc: "'Gregg Kellogg'" <gregg@kellogg-assoc.com>
Message-ID: <015d01ccb03c$a3538d70$e9faa850$@lanthaler@gmx.net>
> 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.


> 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.

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.


> 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.


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


--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 1 December 2011 15:20:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC