Re: Data spaces draft

On May 16, 2012, at 09:43 AM, Sandro Hawke wrote:

> On Wed, 2012-05-16 at 09:23 -0400, Kingsley Idehen wrote:
>> On 5/16/12 8:24 AM, Guus Schreiber wrote:
>>> 
>>> Personal note: after reading I felt quite comfortable with the term "space". Looks like a decent choice. 
>> 
>> Note, your mail subject heading reads: Data spaces, the document title is: RDF Spaces and Datasets. I think you a vindicating a critical intuition that is inadvertently obscured re. this document.
>> 
>> Sandro: please make the document title: RDF Data Spaces and Datasets. This will go a long way to making folks (esp. those outside this community) grok the subject matter covered by the document. If you don't want to change the title, that's also fine by me, but please close this matter either way (for me) via a clear Yes/No response. Interpreting  silence is eternally challenging  :-)
> 
> I wasn't answering because I thought I had been clear I wanted to defer discussion on the term, but since this is clearly very important to you...   my answer for now is a very respectful and slightly tentative, "No".
> 
> (Obviously if the group decides to go forward with this draft, the WG can decide differently, but since I guess this is just my proposal for now, it ends up being my call, for now.)
> 
> I like the sound of "data spaces" and it certainly makes a better title, as you point out, but right now they are defined as being spaces for _graphs_.   The title "RDF Data Spaces and Datasets" rather strongly suggests, I think, that these spaces could also hold _datasets_.   It even seems to be making the point that RDF data is triples *or* quads.

Sandro --

I'm OK with the implicit suggestions you seem not to like, because I think that RDF data *does* include both triples *and* quads, and that RDF Data Spaces *can* hold RDF Datasets (and vice versa!) ... 

"and" is ambiguously commutative.  This title should mean the same with a bit of word shifting -- but none of these permutations I can think of seem to me to communicate quite the same meaning as any of the others --

- "RDF Spaces and Datasets"
- "RDF Spaces and RDF Datasets"
- "RDF Datasets and Spaces"
- "RDF Datasets and Data Spaces"
- "Datasets and RDF Spaces"
- "RDF Data Spaces and Datasets"
- "RDF Data Spaces and RDF Datasets"
- "RDF Datasets and RDF Data Spaces"

I would suggest title rev to "RDF Datasets and RDF Data Spaces".  

I think this breaks (some, most, all?) of the implications you don't like (and breaks more of these than its closest cousin, "RDF Data Spaces and RDF Datasets"), and easily leads into definition of the two terms, and then discussion of how they interact and otherwise operate...


> It might be that the design can be reworked to allow that, but I'm not ready to try that yet.
> 
> Also, I think it might make sense to rename g-snap, too:   g-snap == graph state, g-box == graph state.   

I'm sure one of those (I think g-snap?) was meant to be "== graph state".  I'm fairly sure the other was meant to be something else, but I'm not sure what that would be...


> I think that matches current usage much better than the current "RDF Graph" definition.   If we do this, then the title might be "RDF Graph Spaces and Datasets" or some such. Also, as I get more familiar with the document, I see spaces coming up in less and less of the text, so maybe the title is just "RDF Datasets" or something.   OR maybe there is no document, and all this stuff ends up in other places.    Long discussion.


The need for "[Data] Spaces" or *some* new term comes because "dataset" and "graph" are both overused, overloaded, and confusing (and yes, that effect is still felt on "RDF graph").

"[Data] Spaces" is a new term in this arena -- and thus we get to define it clearly.

I think dropping it because you're familiar with the conversation will just bring us back to where we were before this document... and that's not a win for anyone.

Ted


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers