Re: Property-name scoping

On 6/27/11 8:24 PM, glenn mcdonald wrote:
> 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:
Glenn,

The issue isn't the triple.

The issue is the fact that RDF syntax has become inextricable with the 
triple and the depth of its semantics ultimately detract from the 
inherent power of triples as basis for graph based structured descriptions.

All I seek, is for the triple to be left alone. If you have a problem 
with triples, that's a whole different matter. Let's resolve a single 
matter i.e., triples do not need to be held captive by RDF syntax. It 
didn't invent the triple. Neither did it invent the concept of Name & 
Address distinction when dealing with data access, data representation, 
or data integration. These are the issues that are solved immediately 
the data RDF and Linked Data a properly separated.

I know you don't like other issues re. RDF, but let's keep those issue 
distinct from the core matter of distinguishing basic EAV/SPO based 
graph representation from RDF re. JSON-LD.

If at the end of the day JSON-LD has to be an RDF mirror, then fine to, 
even if we don't like it. The key thing right now is for JSON-LD to be 
crystal clear about what it is and its target audience. The lack of 
clarity in this realm (graph based whole data representation via 
hyperlinks) is really frustrating, to put things mildly.



-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Monday, 27 June 2011 20:35:08 UTC