--- Leopold Toetsch <[EMAIL PROTECTED]> wrote: > James Michael DuPont wrote: > > > > The redland rdf api provides a good C api into rdf. > > > > The advantages of using rdf instead of a homegrown format are the > > amount of tools available, you then have filters, and visualization > > tools immediatly available. > > First I have to admit: I don't like XML.
I dont either. ;) XML sucks. Logic rulez. I have been using timbls n3 notation http://www.w3.org/2000/10/swap/Primer >Second I don't want an > external > library at such a central place inside Parrot. Yes. We can make a native structure. The only thing is this basic api. We dont need to 1. you represent the ast as a set of triples (maybe quads with context) so each thing is a statement like : subject predicate object [context]. 2. You can transform or flatten any ast into a set of triples that is the only real support that I need from you. Basically a set of functions that can be used to emit any ast as a set of logical statements. The logical statements can just be parrot arrays and the user can figure out what to do with them. 3. you can build an ast out of such triples. The only support needed is to have some way to lookup the type of predicate by a name, or to reference an ast node by id. Then we can write various parser in parrot that use this api. I guess the input could also be a parrot array with three columns. 4. You register new predicate names (i have been extracting them from the gcc) you can see some of those here http://introspector.sourceforge.net/2003/09/ildasm_header_micront.owl That could also be an array of known predicates. Each statement could just contain the index to them. 5. we dont need an rdf parser or n3 parser, but can factor that out like redland does : in fact, the only api needed to be implemented is the rdf.storage and rdf.model. those two represent the parsed state of an rdf document and the way to interface to the representation. The rest can be left out of the core. >I also think (hvaing a > > short look at redland-0.9.14, that this might be some overkill to use > > that as the AST interface for parrot. yes. We can make a very cut down api and simple (parrot) provider for n3. The Eulersharp code can be compiled later to parrot via dotgnu. http://eulersharp.sourceforge.net/2003/03swap/ > > OTOH ... > > > > Later on when we have a two-way gateway, then you will be able to > use a > > proof engines to do rule-based tweaking of your AST before sending > this > > off to the backend for execution. > > ... ab interface to RDF would be for sure a nice to have. Yes, I am really interested in the ability to plug in a proof engine and feed it rules to tweak the code. The format is really *egal*. (sorry for the extreme-denglishing) > > > > I hope that you do not get annoyed at this suggestion, if you feel > it > > is off topic, please tell me. > > No, not at all. Thanks for your input. Ok, then you get more. :) schöne Grüsse aus Frankfurt am Main, mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
