Chris, (01)
That preference isn't puzzling at all: (02)
> I find the preference for triple stores puzzling. SPARQL
> doesn't provide aggregate operators or the ability to construct
> intensional predicates (views) using standard boolean operators.
> This pretty much kills it for serious scientific work as far
> as I'm concerned. (03)
The choice of triples is a typical example of the implementers
simplifying their job by shifting the burden to the users. That
happens all the time. The solution is to fire those implementers. (04)
>> ... it is so simple to encode a n-tuple as n triples.
>
> Well, yes and no. The problem is that as soon as you reify n-ary
> relations, you lose the ability to apply unary property constructs
> such as transitivity and role chains, at least using the constructs
> given to you in the languages which are typically layered on to RDF.
> You can perhaps recapitulate some of these in SWRL by essentially
> defining your own n-ary OWL but this is hard and kind of defeats
> the point of staying within a limited subset. (05)
That is certainly true. (06)
In my previous note, I mentioned that Google adopted JSON instead
of RDF as their preferred notation for encoding tuples. However,
the Google software is proprietary, and it's not a standard. (07)
But JSON itself is standardized by ECMA as the native data format
of ECMAScript (AKA JavaScript), and there are open-source import
and export routines for all major (and dozens of minor) programming
languages: (08)
http://www.json.org/ (09)
If you want to represent an RDF triple in a readable format,
you don't need R3 because you can write it in JSON as (010)
[URI-1, RelationName, URI-2] (011)
For generality, it's better to put the relation name in the
first position, because JSON lets you have as many items
as you like in the list. (012)
You can write a list of triples or n-tuples in JSON as (013)
[Tuple1, Tuple2, Tuple3, ..., TupleN] (014)
You can even download free JavaScript code to translate JSON
to or from RDF: (015)
http://www.gbv.de/wikis/cls/RDF_in_JSON (016)
You can also translate tables and tuples from a relational database
to JSON. Following is a row of a table with the column names in
front of each value in the tuple: (017)
{"Emp": "Barack Obama", "Company": "US Gov't", "Title": "President"} (018)
Similar encodings can be used to represent frames and description
logics that are far more readable than OWL. (019)
> ... it's ironic that the majority of SPARQL queries return n-ary
> relations, rather than graphs. However, those n-ary relations
> cannot then be used in subsequent queries - a massive limitation. (020)
If you want to overcome this limitation, type "JSON SPARQL" to
Google to get 82,200 hits. There are also native JSON query
languages named JPath and Jaql. You can also type "JSON SQL"
to Google for 1,860,000 hits. (021)
It's also possible to use JSON to represent the basic formats of
many different kinds of reasoners, including description logics,
frame systems, etc. There is open-source software available
to map JSON to and from Prolog and LISP formats. (022)
JSON can also be used with XML -- in fact, the very widely used
AJAX software (which supports Google Maps, among other things)
uses both JSON and XML -- but it definitely does *not* use RDF. (023)
Summary: JSON is upward compatible with RDF and provides vastly
improved readability, flexibility, and data compression. The
only reason why the W3C doesn't promote JSON as a replacement
for RDF is that JSON is "counterstrategic". (024)
John Sowa (025)
PS: When I was employed by IBM, I submitted a definition
of 'counterstrategic' for the _Dictionary of IBM Jargon_: (026)
Embarrassingly superior to what is strategic. (027)
I also submitted a definition of 'strategic': (028)
Supported by managers who have been promoted beyond their
level of competence. (029)
The editor of the dictionary originally accepted both of
those definitions, but he was later advised to remove them
-- because they were "counterstrategic". (030)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (031)
|