RE: [PEAR-DEV] Re: rdf in pear .. here we go

> From: Davey [mailto:davey@php.net] > Sent: Friday, November 21, 2003 9:54 AM <snip> > 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. See below for a class hirarchy. > > 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? Ok, I guess we can go RDF. > > 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 Well users have to create instances all over the place. Anyways I think it is critical that there is no more then a sed script between each version. Generally I would like to leave the development lead with them as well. This should remain their package. I don't want the fork to split up the resources. > > 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. Yeah this one could be done away with. Its just an interface .. dunno if they have elaborate plans for it though. Ok here is my class tree. Remember that all underscores map to a "/" in the file system. So Foo_Bar will be Foo/Bar.php in the filesystem. Here is a class tree I quickly wipped up: Base Package: RDF o RDF_Object o RDF_Node o RDF_Resource o RDF_BlankNode o RDF_Literal o RDF_Model o RDF_DbModel o RDF_MemModel o RDF_DbStore o RDF_Statement o RDF_Parser (*) o RDF_Serializer (*) Subpackage: RDF_RDQL o RDF_RDQL_Engine + RDF_RDQL_DbEngine + RDF_RDQL_MemEngine o RDF_RDQL_Parser o RDF_RDQL_ResultIterator Subpackage: RDF_N3 o RDF_N3_Parser o RDF_N3_Serializer Subpackage: RDF_NTriple o RDF_NTriple_Serializer Subpackage: RDF_Util o RDF_Util Subpackage: RDF_StatementIterator o RDF_StatementIterator (*) I did not introduce an XML here because I felt this is not standard. As far as I know XML is the "default" serialization format and it is called RDF. So yes this would change the filesystem structure. So what would be the list of changes now then? 1) clean up the code to be PEAS CS compatible - fix whitespaces, brackets etc -> code beautifier jobs (this one they would appreciate) - fix class names (this one they are willing to accept as long as it is reverseable with a script) - fix filesystem structure (this one I didn't not talk to them about, but I feel this structure would actually be more clean) 2) add PEAR Error class (this one I didn't not talk to them about, but I would assume they would welcome such a class as its not like they are scared of instantiating lots of classes) BTW: Arnaud I heard you also wanted to help out? Regards, Lukas