Re: RDF Graphs and Stores Summary

Ivan Herman wrote:
> Nathan,
> 
> first of all, thank you for writing down the issues...
> 
> My problem with what you write is that you seem to make assumptions that I would not make. You write, below:
> 
> [[[
> an RDF Graph is in many ways (almost-) immutable, that is to say that an RDF Graph is a set of triples to which you can add more triples, but you cannot remove triples from
> ]]]
> 
> and I am not sure why that would be true. A Graph is a set of triples; as such, it should be possible to add _and_ to remove triples to and from a Graph. Whether the filter operation returns an array of triples or a separate Graph is a different issue. Also, whether merge means returning a new graph, or you can merge a graph into another one is again a different issues, maybe both operations should be available.
> 
> (I am a little bit afraid that you are influenced by the analogy of an array. Well, the array might be a way to implement a Graph in Javascript but, conceptually, it is a set. As such, removal and addition shouldn't be a problem.)

Yup I agree, just Array is the closest thing to a set in javascript, 
hence it's mention and consideration, other than that though, no bearing.

Without forking the discussion too much though, to quickly address the 
immutable comments, somewhere in my trawls of the layers and depths of 
the semantic web and RDF, I came to the understanding (or read) that 
there is but on giant global graph of statements, which you can augment 
with more statements (say more things) but which you cannot remove 
statements (unsay something). For some reason I've taken this as a Truth 
and it's influenced my conceptual model of things. Is this incorrect?

> Bottom line: I do not see why making a separation between a Graph and a Triple Store. I do not see the value of differentiating between the two (but yes, we need the RDF Graph store abstraction, I agree with you!)

Okay, IIRC previously you mentioned in a thread that you thought 
remove(triple) was out of scope, is this correct, and is it still your 
opinion?

>> - Are an RDF Graph and an RDF Triple Store distinct?
> No.

I won't argue that, I'll suggest that some Triple Stores are quite 
different to a Graph, but not always, and often they are almost 
indistinguishable.

>> - Can we use an RDF Triple Store instead of an RDF Graph in the API?
> 
> No. At that level of abstraction these are the same, and 'Graph' seems to be a logical name.

Can roll with that too, a set of triples regardless of the wrapping 
methods and functionality exposed is just a set of triples. Grey area! 
but I do think calling it "Graph" will keep the focus correct and 
perhaps help with important design decisions.

>> - Should we use an RDF Triple Store instead of an RDF Graph in the API?
> 
> See above.
> 
>> - Which of the three interfaces should we define as part of the RDFa API, [ RDF Graph, RDF Triple Store, RDF Graph Store ]
> 
> RDF Graph, with the provision that two instances per document should be available, ie, the processor and the default graphs

Agree, but also have to point out that there may be an unbounded number 
of graphs, but yes definitely two per document (even if one is empty).

>> - Which of the three interfaces might we define as part of a note?
> 
> RDF Graph Store

agree.

>> And after that rather lengthy email, here's my personal opinion:
>>
>> - Define an "RDF Graph" interface (aligned with Array in javascript)
> 
> I am not sure whether the 'aligned with Array' is necessary. Conceptually, this is not an array nor should it be; it is a set. That being said, if Javascript is too poor to do it otherwise, I yield to you guys' wisdom on that!

conceptually no, useful for js yes, is my opinion on that.

>> - Expose a property or method on the DataParser interface which gives access to the "processor graph" as required by RDFa Core.
> 
> ... and the default graph, yes.
> 
>> - Assert that we have two as-yet-undefined interfaces, "RDF Triple Store" and "RDF Graph Store"
> 
> Only the Graph Store
> 
>> - Clear the issues and get the next editors draft of the RDFa API done.
> 
> of course:-)

:)

>> - If we have time, define one or both of the Triple Store and Graph Store interfaces, in a note.
> 
> ... and maybe some additional methods and interfaces that the RDFa API does not really need but a more general RDF does. I think we should really plan for that note, that can be written once the RDFa API is, say, in last call or candidate rec.

agree

> 
> P.S. Here is the rough RDFLib Graph interface translation, for comparison
> 
> class Graph :
> 	add()		# add a triple
> 	remove()	# remove a triple
> 	triples()	# an 'iterator', ie, it returns
> 			# and array of (s,p,o) tuples
> 			# the request can use a simple filter
> 			# by specifying a specific s, p, or o value
> 			# or None for 'anything'
> 	query()		# essentially an entry point of a sparql query on
> 			# that graph, returning an array of (s,p,o)
> 	serialize()	# returns a string serializing the graph 
> 			# in turtle, xml, etc
> 	parse()		# parse a source in a specific format into the graph
> 	__add__()	# a Python idiom to allow for a g = g1 + g2 
> 			# operation for a merge
> 	__iadd__()	# a Python idiom to allow for a g += g1 operation
> 			# for a merge
> 
> there are some other methods, like shorthands, but these operations are the essential one for each graph. This is not really different than what we have, actually...

Now this is interesting, you see when working through the API I've found 
it very beneficial to decouple query, parse, serialize from graph, and 
instead have

class Parser {
   parse(doc, graph)
}

class Query {
   query(query, graph)
}

Then on the next level of some api have them joined together:

class api {
   attr graph;
   parse(doc, ?graph)
   query(query, ?graph)
}

which enables both styles. Any comments re this for the RDFa API?

Best,

Nathan

Received on Friday, 5 November 2010 11:40:54 UTC