Re: RDFa API - graph?

Hi Nathan,

I know this is not meant to be a completely precise discussion :) but
I'm a little worried that we might lose sight of our vision here.

Of course we want to support RDF programmers.

But we have also said many times that we want the API to be usable by
JavaScript programmers.

We need to constantly remember our constituencies and for the latter
constituency, if, as you say, they

> ...have to deal with triples, subject, predicate,
> object, plain literals, typed literals and so forth.

then we have failed!

As it happens, 'graph' is no longer a computer-sciency term; thanks to
Facebook most programmers will be familiar with the idea of the
'social graph' that expresses relationships between people, so all we
need to do is indicate that we have a mechanism for managing and
querying graphs of all types.

But even that point is moot since the novice programmer will begin
with data stores, not graphs -- the store should manage one or more
graphs, which gives programmers a choice as to which of these levels
they wish to interact with the data.

Regards,

Mark


On Sat, Oct 30, 2010 at 6:52 PM, Nathan <nathan@webr3.org> 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!
>
> 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/
>>>
>>
>
>
>

Received on Sunday, 31 October 2010 11:33:43 UTC