Re: rdf in pear .. here we go

Lukas Smith wrote:

Hi, ok following on the heels of the XML_Annotea (http://marc.theaimsgroup.com/?l=pear-dev&m=106724772231481&w=2) proposal I got myself involved in Davey's efforts to get RDF support into PEAR.

Yay!

Speciafically the RDF parser class (http://phpxmlclasses.sourceforge.net/show_doc.php?class=class_rdf_parser.ht ml) and the RAP RDF API (http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/). I contacted the author of the RDF parser class and he was kind enough to allow the class to be distributed under the LGPL (as I forwarded a while ago).

This is good :)

I also just met up with the authors of RAP (as the conveniently live 30mins from my home) and discussed getting their code into PEAR. They follow our CS more or less, so only minor beautifications would be needed. There are some problems with the class names however. I would say their stuff is interconnected enough that a simple prefix should do.

When I first looked at the code, I was under the impression that we could make this seperate packages for each part... having USED the code in XML_Annotea, it makes little sense (if any) to ever use the different parts seperately.

They suggested the more future proof "RAP" instead of "RDF" to be more open for competition. I am not yet sure if or how to separate things into subpackages. However they were not very fond of touching the class names for BC reasons and also because it would add a lot of useless characters to user code.

I'm not sure on the thinking here. I thought PEAR was against code duplication, wheres the competition going to come in?

If you take a look at their tutorials (http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/tutorial/getting_started.h tm) you will find that users have to create a lot of class instances all over the code so its quite annoying. For that reason they would of course prefer to leave the class names as is. I don't see how we could do that. So my proposal was essentially that we maintain a fork with only the class names changed plus we would maintain sed scripts to convert things back and forth.

I think that the move to PEAR CS et al; should be done in one big swoop. I'd imagine that the PEAR users we bring to this will never have used RAP before, and therefore won't have any problem. If we're going to fork, we should change it all over. Problem we have is for example, the data type objects, theres a lot of changing needed if we change those... but I have a thought, why not assign the class names for the types to constants? that we could *easily* change the class names between the two forks without users having to change much. RDF_LITERAL, RDF_BLANK_NODE etc

They are hoping to get more exposure and also to get some helping hands. I guess the first step would be doing some little code beautifications (nothing big) and come up with a packaging concept for all the classes plus writing the above mentioned sed scripts.

Yes, I think the biggest changes will filesystem changes. Something like this (very roughly made up right now on the spot): $pear/RDF /Parser.php <--- RdfParser class /Parser/ /Parser/N3_Parser.php <--- N3Parser class /Parser/XML_Parser.php <--- RdfParser class /Parser/model/ /Parser/model/blank_node.php <--- Blanknode class /Parser/model/DB_model.php <--- DbModel class /Parser/model/DB_store.php <-- DbStore class /Parser/model/literal.php <--- Literal class /Parser/model/mem_model.php <--- MemModel class /Parser/model/model.php <--- Model class /Parser/model/node.php <--- Node class /Parser/model/resource.php <--- Resource class /Parser/model/statement.php <--- Statement class /RDQL.php <--- RdqlParser class /RDQL/ /RDQL/Base.php <--- RdqlEngine Class /RDQL/Query.php <--- RdqlMemEngine class /RDQL/DB_Query.php <--- RdqlDbEngine class /Serialize.php <--- new class, front end for N3/XML serialisers /Serialize/ /Serialize/N3_Serialize.php <--- N3Serialize class /Serialize/XML_Serialize.php <--- RdfSerliaze class /Util.php <--- RDFUtil class /Iterator.php <--- StatementIterator class I think perhaps we should remove the Object class, it really does nothing but get *one* method inherited and that method gets overloaded anyways.

Comments appreciated! And arm raising for helping in the clean ups as well!

Consider both done! - Davey