Re: RDFa API - graph?

Hi Ivan,

I think simply renaming from store to graph is not what we want here
-- what we actually need is for a store to hold many graphs, which in
turn requires introducing some new concepts and interfaces.

By having both graphs /and/ stores we allow developers to choose
whether they interact with data at the level of graphs (advanced/RDF
programmers) or stores (those who are less concerned with RDF).

Please see the final section of this email for a summary of the arguments:

  <http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jun/0027.html>

The key point I'm trying to stress about having graphs /and/ stores is this:

  The problem with saying that everything I have just described [in that
  email] could just as easily apply to individual stores is that whilst graphs
  differ by provenance, stores may differ by implementation.

For example, I might load your profile and from it extract that you
are based in Amsterdam and have the Twitter account 'ivan_herman'. I
might then use that information to call a geocode service to get your
location as well as query the Twitter API for your latest tweets,
placing each of these two sets of /new/ data into their own separate
graphs, but in the same data store.

By having separate graphs I can keep their provenance separate, and so
manage them independently; I might refresh the geo location graph when
your address changes, and I might refresh the 'latest tweets' graph
every hour.

But by having one data store that holds all of these graphs I can
query across all three as if they were one graph. For example, when I
want to put your tweets on a map I need the tweets from one graph, the
location from another, and your name from the original default graph.

Finally, by having one store holding these three graphs I can place
them all into the same storage medium, perhaps HTML5 local storage
rather than just 'in memory'.

In short, graphs are great for tracking provenance, and making
management of a discrete collection of triples easier, whilst stores
are great for grouping graphs, and for drawing distinctions at the
implementation level.

Note that the simplest scenario -- for the so-called 'novice'
programmer -- is a single data store with only the default graph in
it. This programmer doesn't need to know anything about graphs,
because they will run their queries and generally interact with the
store as a whole.

Regards,

Mark


On Sun, Oct 31, 2010 at 8:15 AM, Ivan Herman <ivan@w3.org> wrote:
>
> On Oct 30, 2010, at 19:52 , Nathan wrote:
>
>> Shane McCarron wrote:
>>> +1.
>>> however, playing devil's advocate for a moment... the problem with 'graph' is that people who don't grok RDF (like me) surely won't grok what a 'graph' is.  'graph' is a very computer-sciency term.  It's the right term in this case.  The problem is that as our audience expands beyond computer scientists to web designers who just want to easily access semantic information from a web page... those people are not in general classically trained CSci majors like some of us surely are.  I
>>
>> Agree but they already have to deal with triples, subject, predicate, object, plain literals, typed literals and so forth. So saying that a graph is a set of triples - or even an array of all the triples in the document, should be a relatively easy learning curve, and more to the point keeps things consistent across all the docs they could read. Users who don't care won't care, but for those who do want to learn more we should make the path as easy and consistent as possible.
>>
>> </gets-off-soap-box>
>>
>>> still think this is the right term.  But a glossary or short definition of the term might help the great unwashed out there.
>>
>> agreed - definitely!
>
> Me too. On both of Shane's count: use the term, and add a glossary item.
>
> Ivan
>
>
>>
>> Best,
>>
>> Nathan
>>
>>> On 10/30/2010 10:18 AM, Arto Bendiken wrote:
>>>> On Sat, Oct 30, 2010 at 5:03 PM, Nathan<nathan@webr3.org>  wrote:
>>>>> Hi All,
>>>>>
>>>>> Just a small thought.. it dawned on me this morning that Graph or RDFGraph
>>>>> may be a better / alternative name for DataStore - personally when I
>>>>> mentally swap out all mentions of store for graph in examples, design and
>>>>> text things feel that bit clearer
>>>>>
>>>>>  graph.add(triple);
>>>>>  graph.merge(otherGraph);
>>>>>  document.data.graph;
>>>>>  serialize(graph);
>>>>>  graph.filter(myFilter);
>>>>>
>>>>> and so forth, it clearly separates the concepts of "Store" (somewhere to
>>>>> store graphs and triples) and "Graph" (a set of triples, an RDF Graph),
>>>>> further, graph is a common concept in the RDFa Core documentation, and all
>>>>> RDF documentation which goes unrepresented in the RDFa API.
>>>>>
>>>>> Anyway, just a thought, I'm sure you get the idea - any opinions?
>>>> +1 for this. In RDF.rb [1], we have repositories and graphs, where
>>>> repositories contain one or more graphs, and those graphs then contain
>>>> a set of triples each. So, I'd have to agree that "Graph" is a better
>>>> name than "DataStore" for a container of triples.
>>>>
>>>> Best regards,
>>>> Arto
>>>>
>>>> [1] http://rdf.rubyforge.org/
>>>>
>>
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>

Received on Sunday, 31 October 2010 12:20:00 UTC