Re: Property-name scoping

The choices are not such a simple dichotomy as you have presented.

For a simple example, namespaces for properties are still necessary in order
to distinguish e.g. "Glenn's hasArtist" from "Pat's hasArtist", assuming
integration across multiple sources is still important.

The differences are generally "structural" vs. "logical". There is a need
for better presentation and tooling, but things should be expected to be
somewhat different because this is a different problem than what most of the
data world has been working on.
On Jun 27, 2011 12:25 PM, "glenn mcdonald" <glenn@furia.com> wrote:
> 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