Re: IRI Templates

On Feb 21, 2014, at 3:54 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 02/21/2014 12:33 AM, David Booth wrote:
>> Personally, I would prefer not to overload JSON-LD this way.  This 
>> essentially amounts to a transformation rule.  And although 
>> transformation rules are useful and neede, I would prefer to have
>> them specified as a separate layer.
> 
> +1 to what David said.
> 
> I'd like to stay away from adding functionality like this to JSON-LD for
> now.
> 
> That said, this is an example of a place where URL templates are useful.
> We should keep it as a concrete example that argues in favor of the
> feature. It seems like a couple of lines of pre-processing code could
> also do the job. The JSON-LD Context doesn't have to be everything to
> everyone and I'm really not in favor of extending it to fit a CSV use
> case (modifying a modern language to fix issues in an older format).
> 
> -1 for the ID template feature for now.

To clarify my thoughts, I see that a JSON-LD frame could be used as a template for mapping CSV to JSON-LD, and much of the additional metadata would be more of an extension to JSON-LD frame format, than a change to the JSON-LD model itself. (Although, I did suggest that IRI templates might be a more generally useful feature in framing). Remember that JSON-LD framing already extends the keyword namespace of JSON-LD, so there is precedent for extensions to do so, and in this sense, a CSV-LD may leverage a JSON-LD format and extend it by allowing other markup to be specified. I still think that this is a useful concept, and is in the spirit of other efforts to leverage JSON-LD to solve more problems.

> One thing we may want to do is specify how extensions to the JSON-LD
> Context should be done, so that one may clearly mark context extensions
> (like the one in this case) w/o confusing older processors.

+1

> Something to the effect of "If you see this property, and you understand
> the extension, process it. If you don't understand the extension, drop
> the property". At least in that case, people could experiment w/ new
> features in production, and if the feature ends up being useful and
> implemented broadly, we could remove the "extension" tag. In this case,
> it would look something like this:
> 
> {
>  "region_id": {
>    "@extension": "http://myparser.com/vocab#idTemplates",
>    "@id": "_:{Sales Region}",
>    "@type": "@idTemplate"
>  }
> }

Conveniently, JSON-LD already says to drop keywords that it doesn't understand, so a general JSON-LD processor would drop these things. I do think that a general-purpose extension mechanism is important for follow-your-nose discovery of these extensions, though. This seems like a reasonable way to go, although the @extension could just be added to the @context, rather than bury it in a term definition.

Gregg

> If the feature gets broad adoption, in time the feature would become
> part of the spec and become this:
> 
> {
>  "region_id": {
>    "@id": "_:{Sales Region}",
>    "@type": "@idTemplate"
>  }
> }
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Worlds First Web Payments Workshop
> http://www.w3.org/2013/10/payments/
>

Received on Friday, 21 February 2014 18:13:14 UTC