Re: [FHIR JSON-LD] Different mappings for different nestings?

> On Apr 18, 2015, at 3:34 PM, Nicholas Bollweg <nick.bollweg@gmail.com> wrote:
> 
> I have wondered if being able to specify a number of the @ keywords inside parts of the context would give us this power. Here's @context inside @context:
> {
>   "@context": {
>     "sns": "http://some/namespace <http://some/namespace>",
>     "person": {
>       "@context": {
>         "name": "sns:personName"
>       }
>     },
>     "organization": {
>       "@context": {
>         "name": "sns:organizationName"
>       }
>     }
>   },
>   "person" : {
>     "dob" : "1975-01-01",
>     "name" : {
>     "family" : "Smith",
>     "given" : "Joe"
>     }
>   },
>   "organization" : {
>   "name" : "Acme"
>   }
> }
> 
> I could imagine this adding a good deal of complexity to the implementation, which I haven't yet attempted... any insights from implementers?

It may be that there is a general mechanism we can introduce that handles this case, and solves some other misunderstandings people have had about the context: If we could introduce a template mechanism, where a term might have an @template property and the contents of that @template would be added to nodes which are the values of a property using that term, this could allow arbitrary JSON-LD to be added when the document is expanded. For example, people have misunderstood the purpose of @type in a term definition to add an @type value to the node when expanding (or generating RDF). A template mechanism could allow this to be expressed, and to introduce other things such as a subsidiary @context.

For example, taking this example (adding @vocab as well):

{
  "@context": {
    "@vocab": "sns",
    "sns": "http://some/namespace#",
    "person": {
      "@template": {
        "@context": {"name": "sns:personName"}
      }
    },
    "organization": {
      "@template": {
        "@context": {"name": "sns:organizationName"}
      }
    }
  },
  "person" : {
    "dob" : "1975-01-01",
    "name" : {
    "family" : "Smith",
    "given" : "Joe"
    }
  },
  "organization" : {
  "name" : "Acme"
  }
}

Expanding this (in stages) might produce the following intermediate results:

[{
  "http://some/namespace#person": [{
    "@context": {"name": "sns:personName"},
    "dob" : "1975-01-01",
    "name" : {
      "family" : "Smith",
      "given" : "Joe"
    }
  }],
  "http://some/namespace#organization" : [{
    "@context": {"name": "sns:organizationName"},
    "name": "Acme"
  }]
}]

Expanding at the next level would yield the fully expanded results:

[{
  "http://some/namespace#person": [{
    "http://some/namespace#dob" : [{"@value": "1975-01-01"}],
    "http://some/namespace#personName" : [{
      "http://some/namespace#family" : [{"@value": "Smith"}],
      "http://some/namespace#given" : [{"@value": "Joe"}]
    }]
  }],
  "http://some/namespace#organization" : [{
    "http://some/namespace#organizationName": [{"@value": "Acme"}]
  }]
}]

> Similarly, being able to specify @vocab inline would be a start towards things like package.json's dependencies:
> 
> {
>   "@context": {
>     "dependencies": {
>       "@vocab": "http://npmjs.org/package/ <http://npmjs.org/package/>"
>     }
>   },
>   "dependencies": {
>     "jsonld": "~0.3.x"
>   }
> }

@vocab is part of @context, so that could be done inside of the included @context. We might also allow as shortcuts the use of @context or @vocab within a term definition to be equivalent to having them inside of an @template, or @template and @context.

Note that re-compacting this to round-trip would be a nightmare, and we would probably have to give up on such round-tripping.

Having a more general @template mechanism could address a number of cases where people expect that the context can introduce boilerplate to their JSON.

Gregg

> Of course, this would suggest that while jsonld would be expanded to http://npmjs.org/package/ <http://npmjs.org/package/>jsonld but so would the version spec... which is still weird. Of course, the relationship is pretty complex: <package> has dependency [has package <npm:jsonld>, has version <npm:~0.3.x>] which would require a lot of model knowledge anyway.
> 
>