Re: playground support


So I'd rather get this done directly ASAP at There are a few
pieces to do, but parallelizable.

1. We need to get rehosted on appspot, so that the homepage can
be content-negotiated. I'm handling that with colleagues at Google. Approx
ETA 1-week to 1-month.

2. We need to be sure that the context fairly represents Is
latest integrated design/proposal from the JSON-LD community,
obsoleting previous sketches? There were some threads with me, Sandro,
Gregg after we spent time hacking around at SemTech. One issue was how we
deal with properties that say can either take a string or a
thing? While generally accepts that publishers will mix these
up, there are a few specific cases where variant value types are
encouraged. Sandro made a nice list and tried to categorize; I'll dig that
out. Looking at the draft above, I see it uses xsd types, and wonder if
those might be a bit strict. What practical effect do they have?

3. We need to get generation of the latest version of a context file
integrated into This is mostly on me. The information we have
that can be used for generating said context file is mostly exposed here, though I'll write something
that generates the context doc alongside the RDFa exporter, based on
internal APIs / code.

While waiting in (1.) I can already fairly easily run copies of
schema.orgon appspot (e.g. we do this for drafts like; while working on (3.) I could make a first cut
that serves a static one-off context file and put it up in that manner for
now. Which makes the generation of this first cut static version of context
the most important thing to collaborate on, for now.



ps. excerpting from earlier thread w/ Sandro+Gregg:
 (for the 17 that are used both ways, I just flipped a coin -- using the
first range that appears.)"--sandro

and from Gregg, """You can always work around the interpretation provided
by the context by being explicit in the JSON-LD. For example:

To always express a value as a literal:

{ "foo": {"@value": "bar"}}

To always express a value as an IRI:

{ "foo": {"@id": "bar"}}

To always express a set of values as a list:

{"foo": {"@list": ["bar"]}}

To express a set of values which are defined to be a list in the context as
a set of unordered values:

{"foo": {"@set": ["bar", "baz"]}} """

On 15 August 2013 21:38, Markus Lanthaler <> wrote:

> On Thursday, August 15, 2013 9:25 PM, David I. Lehn
> > I just added a feature to the playground to use a custom
> > documentLoader to map "[/]" to
> > "". This should let examples
> > [1][2] actually work instead of just complaining about an invalid
> > context URL. We can remove those map entries when/if starts
> > serving their own context.
> [...]
> > Other systems that process JSON-LD may need to use a similar hack to
> > handle incoming data using a context.
> I have been thinking about this for a while now but came to the conclusion
> that it would be too dangerous to do so. In my opinion it sends the wrong
> signal. Especially if it is done without users knowing what happens.
> The danger I see is that this will become the default for large
> organizations and will put a lot of pressure on implementers to do the
> same.
> As long as those examples don't work with existing processors the pressure
> is where it belongs ( in this instance).
> So I would prefer to revert those changes or, even better, to make the
> feature a bit smarter. If the remote context is detected, we
> could display a message explaining the situation (the context isn't there
> yet) and provide users an option to use the context in the
> meantime. Nothing should happen automatically and the user should be made
> aware of the current problem.
> Would that be ok for you?
> --
> Markus Lanthaler
> @markuslanthaler

Received on Thursday, 15 August 2013 21:00:28 UTC