Re: Property-name scoping

On Jun 27, 2011, at 12:24 PM, glenn mcdonald 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

How would I express that one artist is a "performer" and another is an "producer" without having to have both be in a separate class? What if some one has two roles? Using Music Ontology, I might express this in JSON-LD as follows:

[{
"@subject": "#album",
"@type": "Album",
"mo:performer": "#artist1",
"mo:producer": "#artist2"
},
{ "@subject": "#artist1", "@type": "foaf:Person" },
{ "@subject": "#artist2", "@type": "foaf:Person" }]

If the predicate is implied by the type of the object, you can't do this.

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