- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 17 Aug 2012 08:39:42 -0400
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: public-rdf-wg@w3.org
On 08/17/2012 08:21 AM, 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
> 2. RDF data source names.
>
>
> 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:
>
> 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 .
>
If we're opening the can-of-worms about naming, I think the most clear
name is "feed". That seems to be what the non-RDF Web industry uses
(eg [1]). I find it a slightly ugly word, but when we're talking about
interoperability situations, it seems to be simple and non-confusing.
When it's just you and your own data, it may be odd to separate your
data into different "feeds", but when you're imagining that you're
providing your data to the world, it makes a lot of sense. When I
started implementing the federated phonebook cases, I found my variable
names, etc, started migrating from "space" to "feed".
-- Sandro
[1] http://support.google.com/merchants/bin/answer.py?hl=en&answer=188494#US
Received on Friday, 17 August 2012 12:40:23 UTC