A while back, I'd begun work on a Python module that I haven't worked on since. It had some features I thought might be useful but no one seemed to be using Python (outside of Metaweb), so I pretty much stopped work on it. However, it did support most of the things discussed here, like named queries, and some things not discussed, like cursor reads. The nice part was that named queries could be made like so:
<br><br>{<br> "query":[{<br> "first:starring":{<br> "actor":"#actor1"<br> },<br> "name":null,<br> "produced_by":[],<br> "second:starring":{
<br> "actor":"#actor2"<br> },<br> "type":"/film/film"<br> }]<br>}<br><br>I don't actually remember if '#' was the indicator I used but regardless, when this query was fed into the client in a similar fashion to what you do in your Perl module:
<br>$handle = Metaweb->new( server / login details here );<br>$handle->add_read_query( query here );<br>What would happen is that #actor1 and #actor2 would be noticed and on a subsequent run of the query, you could do:
<br>$handle->send_read_envelope(actor1="Jeff Goldblum", actor2="Kevin Bacon");<br>$handle->send_read_envelope(actor1="Bob Saget", actor2="Kevin Bacon");<br><br>(I have no idea how Perl works but this is how it would be in Python, anyway).
<br><br>There also was a function that could read all cursor results into an array for you without you needing to do any bookkeeping of cursor ids.<br><br>I'm not sure if the former would be practical in every language but I would think the latter is necessary for anyone who wants a reasonably large set of results without any timeouts.
<br><br>Hope this helps,<br>Vishal<br><br><div><span class="gmail_quote">On 8/12/07, <b class="gmail_sendername">Hayden Stainsby</b> <<a href="mailto:hds@caffeineconcepts.com">hds@caffeineconcepts.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Firstly Perl module stuff (skip if you're not interested in Perl):<br>I'm hoping to release my Perl module to CPAN at some point this week,
<br>however at this point it's likely to be just Metaweb, not<br>Net::Metaweb, as the guys on the modules mailing list pointed out<br>that Net::* isn't the right place for it and I can't find another<br>namespace that matches what it does. Sorry to Kirsten and anyone else
<br>who has started using it - any existing code will have to change to<br>reflect the new namespace, I'll update everyone when it's ready.<br><br>Next general Metaweb module stuff:<br><br>I agree it would be worthwhile agreeing to some sort of standard set
<br>of functionality that would work across languages. The difficulty of<br>course is in creating a set of guidelines that make sense for both<br>procedural and object orientated languages.<br><br>I started off looking at a concept similar to Shawn's, but found that
<br>it meant giving up MQL's ability to send multiple queries in one<br>envelope. So I'm working on a structure for sending a query that is a<br>little more complex (one method call or so), but I think that even a
<br>programmer fairly new to Perl should be able to get it up and running<br>fairly quickly.<br><br>In brief Perl-ish syntax:<br><br>$handle = Metaweb->new( server / login details here );<br>$handle->add_read_query( query here );
<br>$handle->send_read_envelope;<br><br>You then access your queries by name. The important point being that<br>you can send multiple named queries (or a single query using the<br>default name if you don't specify a name) using the same calls.
<br><br>You then also need a separate method/function to access the trans<br>service to fetch pictures and body text. But that's pretty straight<br>forward, all you need to use there is the translation type and the<br>
guid of the object you're fetching.<br><br>The last thing that I think is worth mentioning is that we need to<br>incorporate the fact that read queries will be able to be performed<br>without authentication (as far as I can tell) once Freebase reaches
<br>beta, and I suppose it's possible that some other Metaweb instance<br>may come along that doesn't require any authentication at all.<br><br>I've suggested creating a type for Metaweb libraries / modules /<br>
frameworks under the Types -> Freebase section along with a suggested<br>setup in my own namespace, if anyone has any suggestions please let<br>me know.<br><br>As far as my module goes I'm planning on adding an further
<br>abstraction (possibly even as a separate module) that allows<br>developers to work without using MQL, but view Metaweb as a pure tree-<br>like structure - in a way it will be programatically like the<br>Cinespin application featured in the developers section.
<br><br>Sorry for my long winded post - I hope it didn't send too many people<br>to sleep.<br><br>--<br>Hayden<br><br><br>On 12 Aug 2007, at 03:36, Shawn Simister wrote:<br><br>> Hi Kirsten,<br>><br>> I agree that a common base would be a good idea even if it just starts
<br>> off as a very small set of features.<br>> So far, in developing a Ruby module for Metaweb, I have been<br>> building on<br>> the following core concepts:<br>><br>> ReadService.read(queries)<br>>
WriteService.authenticate(host, user, password)<br>> WriteService.write(queries)<br>><br>> As each layer of abstraction is added, the API becomes more language<br>> specific so at some point there will be certain features that Ruby can
<br>> do but more rigid languages like Java couldn't. Still, I think<br>> there is<br>> enough overlap to warrant a common knowledge base of source code and<br>> best practices for API developers. Each API would be allowed to grow
<br>> organically while maintain compatibility with Metaweb Core 1.0 (for<br>> example).<br>><br>> Can anyone from Metaweb comment on if Metaweb would want to get<br>> involved<br>> in a standard like this?
<br>><br>> Shawn Simister<br>><br>> Kirsten Jones wrote:<br>>> All,<br>>><br>>> I'm just about ready to start working with Hayden's perl module, and<br>>> had some thoughts I wanted to bounce off of the rest of you.
<br>>><br>>> On the more general topic of modules, I'd really love for the<br>>> developer community to come up with a set of guidelines for client<br>>> libraries for Metaweb. Each language's library might well have
<br>>> additional functionality, but I'd love to define what the 'base<br>>> functionality' for each library should be. Doing this will make it<br>>> easier for people to move among the various dynamic languages and
<br>>> leverage off of other people's work in different languages to seed<br>>> their own applications. It seems like it would also make it easier<br>>> to create the client libraries if some essential set of behaviors is
<br>>> already specified.<br>>><br>>> Metaweb is so flexible that I'm afraid if we *don't* come up with<br>>> something like this, the modeling in each language may end up being<br>>> radically different.
<br>>><br>>> Since I currently work at a wiki company, I was thinking of creating<br>>> a workspace for people who are interested in collaborating on what<br>>> these guidelines might be. But I thought I'd start here and see what
<br>>> people think - good, bad, indifferent? There are certainly arguments<br>>> to be made for allowing these things to grow organically.<br>>><br>>> Thanks,<br>>> Kirsten<br>>> _______________________________________________
<br>>> Developers mailing list<br>>> <a href="mailto:Developers@freebase.com">Developers@freebase.com</a><br>>> <a href="http://lists.freebase.com/mailman/listinfo/developers">http://lists.freebase.com/mailman/listinfo/developers
</a><br>>><br>>><br>><br>> _______________________________________________<br>> Developers mailing list<br>> <a href="mailto:Developers@freebase.com">Developers@freebase.com</a><br>> <a href="http://lists.freebase.com/mailman/listinfo/developers">
http://lists.freebase.com/mailman/listinfo/developers</a><br><br>#!/usr/bin/perl<br>chop($_=<>);@s=split/ /;foreach$m(@s){if($m=='*'){$z=pop@t;$x=<br>pop@t;$a=eval"$x$m$z";push@t,$a;}else{push@t,$m;}}print"$a\n";
<br># <a href="http://occasionallyhuman.net/">http://occasionallyhuman.net/</a><br>#9202a8c04000641f80000000054c75be<br><br><br>_______________________________________________<br>Developers mailing list<br><a href="mailto:Developers@freebase.com">
Developers@freebase.com</a><br><a href="http://lists.freebase.com/mailman/listinfo/developers">http://lists.freebase.com/mailman/listinfo/developers</a><br></blockquote></div><br><br clear="all"><br>-- <br>:v