W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2004

Re: Reification - whats best practice?

From: Leo Sauermann <leo@gnowsis.com>
Date: Sun, 29 Aug 2004 21:10:41 +0200
Message-ID: <41322A31.8000000@gnowsis.com>
To: Bob MacGregor <macgregor@isi.edu>
CC: Frank Manola <fmanola@acm.org>, www-rdf-interest@w3.org

But its actually worse than that.  To get decent performance while using 

> you have to make modifications at the implementation level.  
> Relatively few users are going
> to build or extend an existing triple store just to get provenance 
> information.  So, the
> "experiment" is going to proceed relatively slowly.  On the other 
> hand, suppose Jena
> implemented quads.  Suddenly, the opportunities for experimentation 
> would increase
> 100-fold (to pick a random number).  Then there would be a flurry of 
> experimentation,
> probably leading to much earlier recognition of what a standard 
> semantics for
> provenance (a step beyond contexts) should look like.

if I had quads in Jena, I would code applications that have

- less lines of code
- are faster
- have much more functioanlity (security, triple updates, etc)

becuase with quads I would be able to to it easily, instead of 
reification crux,
I don't need hot air from people who do not code. I need good ideas from 
people who want to create features for people, that are affordable and 
can be implemented.

YES i already implemented a "tagging" api that identifies subgraphs in 
my graph by putting hte triples reification  in a Bag and then for 
example deleting the bag and all triples for doing updates.

I will show you:

with quads it is:

(pseudocode for adding)
 for (StmtIterator i = data.listStatements(); i.hasNext(); ) {
           Statement s = i.nextStatement();
            target.addQuad(ID, s);
(pseudocode for delete)
target.deletequad(ID, *, * ,*)

so thats 5 lines with imaginary quads.


        // extract all THETRIPLES into a vector to avoid infinite loop 
        Vector theTriples = new Vector();
        for (StmtIterator i = data.listStatements(); i.hasNext(); ) {

        // do the tagging of THETRIPLES
        // add the dataTag to the data
        Resource dataTagR = tag.addTo(data);
        // put all triples in a bag
        Bag bag = data.createBag();
        for (Iterator i = theTriples.iterator(); i.hasNext(); ) {
            Statement stmt = (Statement)i.next();
        // add the bag to the datatag
        dataTagR.addProperty(DATA.triples, bag);

        // add THETRIPLES and the tag to the repository
        // close data

Removing it:
        // buffer the model
        Model model = server.getRepository().getModel();
        // get all Resources of reified statments
        Bag tripleBag = tag.getProperty(DATA.triples).getBag();
        Vector reifications = new Vector();
        NodeIterator i = tripleBag.iterator();
        while (i.hasNext()){
            RDFNode node = i.nextNode();
            if (node.canAs(ReifiedStatement.class)) {
                ReifiedStatement reified = (ReifiedStatement) 
                throw new GnowsisException("iterating through dataTag 
"+tag.toString()+": node "+node.toString()+" is not a statement");
        // convert to array
        ReifiedStatement[] reifyArray = (ReifiedStatement[]) 
reifications.toArray(new ReifiedStatement[reifications.size()]);

        // remove everything from bag, the contents of the bag is noted in
        // rdf:li_0, rdf:li_1 ...

        // remove the statements and reifications
        for (int j = 0; j < reifyArray.length; j++) {
            // remove reification
            // statement
            Statement s = reifyArray[j].getStatement();
            // remove all reifications
            // model.removeAllReifications(s);
            // remove statement
        // remove the bag

quite long, eh?

> Right now, the people adopting your position are consigning the 
> majority to a
> Gedankenexperiment, where the expected rate of progress will be about 
> what it
> is in the relational database community -- nil.


Received on Sunday, 29 August 2004 19:11:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:52 UTC