Stephan Bergmann wrote:
Michael Stahl wrote:
Stephan Bergmann wrote:
Some more input:
[snip]
- Not sure if the modifying methods of XRDFNamedGraph are necessary
(or if they are only added to allow implementing XRDFRepository
together with an "alien" XRDFNamedGraph implementation; in which case
some private protocol between an XRDFRepository and the
XRDFNamedGraph objects it creates might be better)---but I am
absolutely not a domain expert with RDF.
if by "modifying methods" you mean addStatement, removeStatement, then
yes, those are the only methods that actually allow to change
repository contents :)
And it is intended that client code calls these modifying methods? (This
is still not clear to me from what you write. I had initially asked,
because if the methods are not really needed for client use, it might be
better to make XRDFNamedGraph objects immutable.)
yes, these two methods are basically the reason why we have this API :)
now, if XRDFNamedGraph is implemented as described below, then it would
indeed be immutable, and just forward the actual work to an underlying
implementation-specific repository object that is not immutable.
note that XRDFRepository and XNamedGraph implementations will be
tightly coupled and not interchangeable.
basically, XNamedGraph can be implemented as just the graph name and a
pointer to the underlying repository implementation.
note further that (hopefully) there is no method in either interface
which takes an object of the type as parameter :)
in other words, there is one underlying repository implementation object,
and this is represented in the api by one XRDFRepository object and a
bunch of XRDFNamedGraph objects.
--
"A programming language is low level when its programs require
attention to the irrelevant." -- Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
