Re: Property-name scoping

>
> 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.
>
True, but that wasn't my point. Rephrased:

There are two main ways to think about property scoping:

- property names must be unique across a whole vocabulary
- property names need only be unique across the set from a single
originating type


> 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
>