- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 17 Aug 2012 13:34:53 +0100
- To: public-rdf-wg@w3.org
On 17/08/12 13:21, Kingsley Idehen wrote: > On 8/17/12 7:37 AM, Andy Seaborne wrote: >> >> Like Steve, the name "space" does not work for me either because of, >> for example, "data spaces". We aren't naming from a clean sheet. >> >> "container" works for me in the figure. Something with the idea of >> containing (like 'slot' graph store). "box"? > > What about any of the following: > > 1. RDF data spaces The whole idea of aligning to "data spaces" does not work for me as I'd expect it to be a collection of graphs with ontology mappings if taken from the whole adapter-"pay-as-you-go" meta meme in current database research. (for anyone lost here : http://en.wikipedia.org/wiki/Dataspaces) > 2. RDF data source names. There is something worth considering in "source"; RDF source RDF data source Triple source Graph source ... > > > Backdrop: > > The terminology alignment between RDF + SPARQL and the broader realm of > DBMS technology (esp. because of SPARQL) is ultimately a win-win. In the > RDBMS realm (as you and Steve know) we have: I agree about the desirability of alignment but getting too close has it's own issues. > > RDBMS - Relational Tables (while RDF stores are basically Relational > Property Graphs) > Tables -- Named Relations comprised of n-tuples > Data Source Names (DSNs) -- for ODBC, JDBC etc. access scoped to > Tables/Views re. data access by reference pattern > Views -- for all intents an purposes this aligns well with > backward-chained inference > Triggers -- for all intents an purposes this aligns well with > forward-chained inference . Andy
Received on Friday, 17 August 2012 12:35:55 UTC