Re: Best Practice for Renaming OWL Vocabulary Elements

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