RE: Forms and principles of the JSOD-LD context

> Of course, maybe you meant that we could reuse @datatype in this
> *different* situation, and thus remove the need for the separate
> @coerce key?

That's exactly what I meant.

> Even if so, I think it'd endanger the understanding of
> what's going on. In fact, I'd might rather replace @iri here with
> something like @mapsTo. Just to clarify that it is a mapping we're
> doing, and not instance data. I think this warrants some discussion.
> In general, I think reuse of terms can be dangerous where precision
> and clarity is needed. That's certainly the case in context
> definitions. When on such a meta level, I'd much rather use specific
> terms than overload anything. (In the same way, using @type would be
> even more confusing, since it'd then look like we're describing the
> property or class -- and hence could be expected to @type them with
> rdf:Property or owl:Class. I.e. far from our intent!)

I looked at it more from a programmers perspective (and I think a lot of
people that will eventually use JSON-LD do). If consider the context as kind
of a header file where all variable declarations are made, I think it would
make sense. So you basically say: In the context (that's the "header") I set
up and declare everything that I'll then use in the main JSON-LD document,
i.e., I map terms and prefixes to IRIs and set their data type. I think
programmers won't have any problems in understanding that the context isn't
about instance data. Even more so if they use external context documents. On
the other hand, the term coercion is typically used to refer to implicit
(automatic) type conversions in programming.

Markus Lanthaler

Received on Wednesday, 2 November 2011 12:30:09 UTC