Re: [All] Proposal: RDF Graph Identification

On 8/17/12 8:39 AM, Sandro Hawke wrote:
> 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.

That depends on the target audience.

In my eyes (and experience) the target audience to win over is the 
broader DBMS community. From that community to tap into a massive 
collection of expertise and experience that will ultimately appreciate 
how RDF addresses an old challenge, in a contemporary way.

Terminology remains the prime hindrance re. the above. Many RDBMS 
experts (e.g., company founders and lead technologists of many major 
RDBMS products) that I encounter still find RDF terminology so alien 
that they completely miss the fact that it provides a solution to their 
biggest problems re. data access and integration.

> 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.

Feeds is a term that's associated with RSS, blogosphere, and Web 2.0. 
Folks that fit into those profiles are anti anything that carries the 
letters R-D-F, so adopting "Feeds" won't get us anywhere, bar wasting 
time we don't have. This is why the DBMS route is more beneficial since 
the same anti R-D-F folks are grappling (indirectly) with the very 
problems that RDF solves albeit via RDBMS and so called NoSQL products.

> When I started implementing the federated phonebook cases, I found my 
> variable names, etc, started migrating from "space" to "feed".

Well that is a feed :-)

>
>     -- Sandro
>
> [1] 
> http://support.google.com/merchants/bin/answer.py?hl=en&answer=188494#US
>
>
>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen