Re: IRI Templates

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.

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.

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"
  }
}

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 11:55:07 UTC