Re: RDF Graphs and Stores Summary

Hey Nathan,

On Nov 5, 2010, at 12:39 , Nathan wrote:

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

Hm... well, conceptually that might be true although this would lead to a kind of a philosophical debate. But that does not mean that you cannot remove a triple from a specific Graph! That does not remove the triple from the universe, just its association with a specific graph instance...

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


Heh:-) Out of scope, probably, for an RDFa API. Not out of scope for an RDF API. From then on it becomes a question of modularization (and I am not sure how to do that): maybe the 'remove' method is only part of our RDF API Note and not the RDFa API part.

[snip]


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

For further (unbounded number) we have the RDF Graph store, but your question was on the RDFa API an not the RDF API.

[snip]

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

I do no have any strong preference for that. RDFLib binds them together and I never felt uncomfortable using it that way. The only reason I listed the example is for the operations that are used and done for a Graph.

Ivan


> 
> Best,
> 
> Nathan


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