On 5/18/11 9:04 PM, glenn mcdonald wrote:
It seems a bit much to expect a query writer/developer to maintain
literally unreadable source code.
That's kind of the point: the humans should be talking in human terms,
not machine terms. SPARQL forces humans to use machine terms, which is
bad.
You're right that using pure IDs for /predicates/ is impractical if
you have to hand-write/maintain queries, but at least your set of
predicates is smaller and more stable than your set of nodes,
generally. And the RDF/RDFS/OWL predicates are almost completely
stable, by definition. So to me using pure IDs for nodes is practical
enough to do with current technology, and making it possible to
separate IDs and names for predicates is an issue to be addressed in
the future, either /in/ SPARQL or by replacing SPARQL.
g
Glenn,
How can SPARQL be the problem? How does SPARQL differ from SQL re. query
languages that facilitate access to data? The issue doesn't lie in the
syntactic realm, this is purely about a fundamental concept, ultimately.
Basically, its about the Semantics of Hyperlinks.
If we are going to use Hyperlinks to construct graphs that represent
Entity Descriptions (delivered as network accessible Resources) then we
need said Links to be able to deliver critical functions:
1. Names
2. Addresses.
Then a Link (basically a tiny app) becomes a bona fide mechanism for
data access by reference and linked data structure construction. Then
when you add the HTTP scheme URI to the mix we end up with the ability
to negotiate the representation of linked data structures (eav/spo
graphs) used as basis for entity description.
There's nothing wrong with SPARQL. Likewise, there's nothing wrong with
RDF bar conflating it with Linked Data :-)
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
