RE: Can you provide some context?

On Monday, April 20, 2015 8:11 PM, Ron Siemens wrote:
> Hi Markus.  I appreciate the tips, thanks!
> 
>> A branch...
>> {
>>  "id":"200",
>>  "name":"root_branch",
>>  "branches":[ { "id":"201", "name":"sub1_branch" },
>>               { "id":"202", "name":"sub2_branch" } ],
>>  "leaves":[ { "id":"500", "name":"leaf1" },
>>             { "id":"501", "name":"leaf3" },
>>             { "id":"502", "name":"leaf4" } ],
>>  "age":"20"
>> }
> 
> ...
> 
>>> I'd like a separate @context for each. Something that I could use for
>>> a header-linked context that exposes the links into the structure.
>>
>>.. but this won't work if you also want to be able to browse the resulting
>>documents as a client wouldn't know how to expand "leaf3" to a full URL.
>>Would it be a problem to change the names to include the directory
>>("leaf/leaf3" instead of just "leaf3")?
> 
> It seems there must be other approaches to this, since I believe
> modifying an existing data model would be undesirable and a last
> resort.

Unfortunately there isn't any practicable other approach. The only
workaround would be to explicitly map leaf3 (and all other such "tokens") to
URLs in the context. But I assume that's not a viable solution unless you
generate a different context for each resource.

>  In my case, these representations are used by existing
> systems that must remain compatible: which is why I'm going with the
> header-linked approach.

I understand the use case but we had to make a trade-off. We decided to
prefer to keep JSON-LD simpler than trying to be able to map any arbitrary
legacy JSON representation cleanly to JSON-LD with just a context.


> Can the context not help in some way here?  Different namespaces for
> the various "name" fields perhaps?  Or using the property names (
> "branches", "leaves" ) to disambiguate the values?

No.


> If the limitation is just due to off-the-shelf clients to browse this,
> I'd rather implement my own client than mess with my data model and
> representations.

The problem is that you have a data model that you only implicitly expose in
your JSON representations. The properties you use are context sensitive (in
the traditional sense; not talking about JSON-LD contexts here). name: x
means something different depending on where it appears. In one case x means
.../leaf/x in another .../branch/x. We aren't able to express that with just
a context. There have been discussions to allow that in future versions of
JSON-LD but that will take a long time. The simplest solution would be to
use content negotiation and server proper JSON-LD.


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 22 April 2015 19:07:19 UTC