Re: RDF Graphs and Stores Summary

Ivan Herman wrote:
>> 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...

good point! thanks.

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

Ahh but we're doing the RDF Interfaces as part of the RDFa API, and an 
RDF Graph is an RDF interface (whereas a DataStore is a Data interface) 
?, either way, yes it's at RDF level but the interface is in our 'API'. 
So we'll need to decide at some point.

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

As above, was on "things in scope for the API document we're doing", 
which includes both some part of an RDF API and RDFa specific 
extensions. But again, can't see that makes any difference, people will 
be able to make multiple instances of Graph, or Store, regardless of 
what we say so it's kinda moot and not sure why I'm still mentioning it!

>>> 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
[snip]
> The only reason I listed the example is for the operations that are used and done for a Graph.

Seems to be a good indication of what we need, and nicely aligned 
actually - only semi-debatable in there is "remove", but minor to implement.

General take away being, remove DataStore, add RDFGraph, do GraphStore 
in a note (along with anything else we see fit) - is that correct? if 
so, +1 from me.

Best,

Nathan

Received on Friday, 5 November 2010 12:21:56 UTC