Property-name scoping

There are two main ways to think about property scoping:

- properties belong to a name-space
- properties belong to the originating type

RDF uses the former, and the proposed JSON-LD specs have followed this
model. Thus, for example, Book has bookFormat and Media has encodingFormat.
Property names must be unique.

Most of the rest of the data world, in my experience, uses (and has long
used) the latter. E.g., Book and Media can both have Format properties with
no confusion, even though these point to different target types. Book and
Reading can both have Author properties, even though these have different
semantics.

I'm not sure whether this was an intentional decision at some historical
point in the evolution of RDF, or if it was an effect of some other
description-logic-y thing. But I think it was a mistake either way. Not only
is it annoying in itself, but it also largely constrains property-*naming* to
use the less popular of the two main styles, which are:

- properties are verb phases connecting type-nouns
- properties are, most of the time, synonymous with their target-type

Thus, in RDF, you get Album -> hasArtist -> Artist and Artist -> hasAlbum ->
Album, whereas in many other data contexts you'd just say Album -> Artist
and Artist -> Album.

Both these are bad design tradeoffs, I think, and maybe-minor-sounding
things that actually end up slowing down or preventing adoption. It seems to
me that JSON-LD has no reason beyond RDF precedent to not optimize for
more-common practice in both cases. Thus this should be a perfectly good
schema:

Album
- Artist
- Format
- # of Discs
- Label

Artist
- Album
- Genre

Format
- Album

# of Discs
- Album

Label
- Album

To support this, the features for mapping JSON keys to IRIs must be
schema-dependent, which the @context mechanism is not.

And if you do that, you'll probably also find yourself wanting to reverse
the structure of the @coerce idea, from [datatype -> types] to [type ->
datatype] (at which point you can call it "@datatype", which is way better
than "@coerce" anyway).

And then you'll already have most of the schema written out in your header,
at which point my proposal to just put the schema into the graph as nodes
and arcs might start making more sense to you...

g