- From: William Waites <ww@styx.org>
- Date: Fri, 20 May 2011 14:31:30 +0200
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: Linked JSON <public-linked-json@w3.org>
* [2011-05-19 16:37:07 -0400] Gregg Kellogg <gregg@kellogg-assoc.com> écrit: ] * The model should be based on the notion of graphs, similar to RDF, but ] where the semantics are more Class/Object based, rather than predicate ] based. (i.e., I define a class definition with specific properties and ] class inheritance/implements more similar to Ruby/Python, rather then ] being predicate based. I'm not sure this is such a good idea. One reason for the resurgence of functional programming languages as well as languages like Go that have concepts of interfaces instead of inheritance is dissatisfaction with the knots one can easily tie oneself into with OO in any reasonably sized project. Thanks to Java being used as a teaching language in schools OO may be a very common way of thinking about data structures but it is not the only way or even necessarily the most desireable way - when you start getting to problems like classification and similarity in KR, OO class hierarchies become a bit of a straightjacket. Looser ideas, like implements/interfaces fare better but they are about *behaviour* and not about *data*. Also, a cursory reading of the literature on graph databases (the Google Pregel paper particularly) suggests that most information is in terms of annotations on links and not on nodes. A predicate is just a link where the annotation is the name of the predicate. For graph-shaped data - data where the objects tend to be URIs rather than literals - this makes a lot of sense. For data where the objects tend to be literals I would agree that a more node-centric representation makes sense. ] * The model should be naturally be processed in web-like languages ] (JavaScript, Ruby, Python, etc.). This is new terminology to me. I'm not sure what a "web-like language" means other than "a language currently popular with web developers". Popularity waxes and wanes so shouldn't be a primary consideration. ] * The need to manage multiple ontologies/vocabularies is a real problem ] for adoption of RDF in many areas. Something that allows a local ] definition of a vocabulary where equivalence to OWL ontologies might ] also be defined, would work better with the actual practice of vocabularies ] in the wild. In JSON-LD, @vocab allows for local definition of these ] vocabularies, and the RDFa @profile mechanism might provide a way to ] define these remotely. I agree this is a big problem. Perhaps the biggest barrier for people starting out with RDF is figuring out which vocabularies are appropriate and how to use them. I think this comes from the attempt to have global scope everywhere (pace blank nodes) and agree that more attention needs to be paid to the idea of local dialects and reasoning on neighbourhoods of resources rather than trying to work with the entire universe of facts simultaneously. This is analogous to the reason why programming languages have the concept of scope and it has long been known that global variables should be treated with suspicion and distrust. Actually I think you may have nailed the key barrier to adoption of RDF here. Cheers, -w P.S. I think blank nodes are just fine and replacing them with what are effectively skolem constants as a matter of policy doesn't hurt but doesn't really change anything either. -- William Waites <mailto:ww@styx.org> http://river.styx.org/ww/ <sip:ww@styx.org> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Received on Friday, 20 May 2011 12:31:55 UTC