would it be possible to reserve @view for JSON-LD v.next

[melvincarvalho]

Hopefully this is the right place to post this topic:

JSON-LD provides a declarative data model for use on the web. However there is no generic way to view that data, by introspecting on it

I had the idea of a @view keyword, which could live at the same level as the @context

It would simply pull in a module that is used to view the data

This could make for some compelling demos where data becomes self displaying

The proposal is simply to reserve the keyword for future exploration

I would imagine @view occurring at the document level at most once, to begin with

It would be quite easy to create a shim that does this, making it possible to create attractive markup for much of the existing data in the JSON-LD ecosystem

This request goes beyond JSON-LD 1.1, to perhaps 2.x or future versions, expected to be some years from now

For now this proposal is simply to reserve the keyword as a place holder, while implementations can be created and then align

Would love to know any thoughts on this!

[gkellogg]

Other than for @context, the only place the spec is particularly restrictive in terms that look like keywords (e.g., "@"1*ALPHA) is in context processing. This is necessary, as other JSON vocabularies may also use @-based terms and for general backwards compatibility.

A way to handle this might be to rely on some as-yet-undefined context rules to describe the behavior of a term which may use something like @view in its definition, but this would require the context be processed to know about any such special rules.

Other than the @context, we don't really have a notion of reserving a namespace for keywords outside of a context definition. Of course, in a hypothetical 2.x version of the spec, semantic versioning could allow us to break backwards compatibility for such things.

Maybe a Wiki page on https://github.com/json-ld/json-ld.org/wiki describes the space of possible future keywords that developers might help foster.

[melvincarvalho]

Other than for @context, the only place the spec is particularly restrictive in terms that look like keywords (e.g., "@"1*ALPHA) is in context processing

Thanks for the clarification, aren't @id and @type also reserved names for predicates?

A way to handle this might be to rely on some as-yet-undefined context rules to describe the behavior of a term which may use something like @view

Great suggestion, thanks. Possibly something I can experiment with

[gkellogg]

Thanks for the clarification, aren't @id and @type also reserved names for predicates?

They have a pre-defined meaning, and a context can't define them otherwise. But, a context sees an attempt to define anything that looks like a keyword as a term, it should issue a warning (Step 5 of the Create Term Definition Algorithm), and they will not expand to IRIs, so will generally be eaten when expanding a document. Look for "form of a keyword" in the API document for other places this is discussed.

[TallTed]

@melvincarvalho -- in https://github.com/w3c/json-ld-syntax/issues/384#issue-1080776762 and https://github.com/w3c/json-ld-syntax/issues/384#issuecomment-995312218

and @gkellogg -- in https://github.com/w3c/json-ld-syntax/issues/384#issuecomment-995350958

Please go back and codefence @context, @id, @type, @view... Those GitHub users are not involved in the deliberations here, and I'm sure they're not helped by notifications that they've been tagged.

[Peeja]

@melvincarvalho Do you have a specific idea for what the value of @view would be, and how it would be used by a user agent?

I wonder if perhaps the best way for the data to make this declaration is in fact with @type, leaving the implementation of viewing that type up to the user agent. Thus, the data remains the data, but a user agent might have a standard way to view any http://schema.org/Person node (and another user agent may have its own way).

[melvincarvalho]

@Peeja I have a rough idea

Things of a certain @type would be like a widget, with linked and nested objects. Those could have a certain kind of view associated with them, or injected into them

The page itself is a special case and could have have an app associated with it, which would then render everything on the page

This is a rough idea, and it would, of course, be completely optional and opt-in

It could be refined a bit as a group, and with implementations. But I think the idea of a @view is complementary to JSON-LD as a model, as per the MVC pattern

[Peeja]

I 100% agree that portable view components like this are a great idea (in fact, I'm super excited about them), but my gut says they should know about the data, and not the other way around. In MVC, for instance, JSON-LD is in the model layer. You wouldn't have a model know about its view; you'd either have the view know about the model, or have a controller know about each of them and coordinate.

That said, it might be useful for the data to be able to hint at a view to use. But I think that could be done with a property from a new ontology, without needing to amend the JSON-LD spec in particular. Using that, it would even be sensible for other graphs to suggest what the view for this resource should be, if this resource itself doesn't know anything about these views.

[melvincarvalho]

@Peeja I think we are largely agreeing that there are a couple of mechanisms with which to associate a view with a model

Which way is more practical or useful may depend on the use case. It's a bit like rel vs rev links. You can always reference "from something" or "to something". And different systems may have different constraints. It might actually be a matter of taste. You could actually work with a model and a view, and not need to create a controller at all, or it could be a simple shim.

A @view term does not preclude doing things one way or another, and could well be complementary.

[Peeja]

Yeah, that makes sense to me. Still, though, I think that can be defined in an ontology and used in any JSON-LD document, without needing to reserve it in the JSON-LD spec explicitly. It would just be a property that could apply to any resource/node. (Don't take that as dismissing the idea, though; I'd love for that property to exist and be used! It could be extremely powerful.)

[melvincarvalho]

@Peeja thanks for suggesting using an ontology. I agree that could be done today, and I'm glad you agree that views could be powerful

The challenge with a vocab is twofold. One is to gain consensus on which to use, and the other is getting developers to use it

Projects such as schema.org have shown that a simple syntax can gain wide adoption with the developer community who are used to JSON, and not advanced ontology usage. I think to gain traction it would likely need to be at the spec level.

That said, certainly @view could map to an ontology. Maybe one exists already,but I dont know of one. Or it might be possible to make one. That might give the best of both worlds

[avnr]

I believe the ontology already exists as schema.org's Action type and its target property. The Action can be not just "view" but also anything else, e.g. "print", "read", "translate", "compile", etc.