On Mar 16, 2008, at 1:52 PM, Markus Krötzsch wrote:
> On Samstag, 15. März 2008, Matt Williamson wrote:
>> Greetings from the presumed-dead author of Semantic Layers. I'm
>> finally starting to update SL for compatibility with SMW 1.0--and
>> having some luck so far, I've made good progress on a subclass of
>> SMWResultPrinter that lets you specify "map" as the format, and that
>> part seems to be progressing well.
> Very nice, the extension surely has great potential in many
>> However, for several of the other features I need to do exactly what
>> you mention below--use the existing SMW objects to submit and process
>> an arbitrary query, and get the results back in a form I can
>> manipulate programmatically. Glad to hear that accessing the database
>> is discouraged, as I was loathe to do so.
>> But I'm having a bit of trouble figuring it out, since the pipeline
>> seems primarily geared towards producing printed output. So, could
>> elaborate a bit on precisely how one might use SMW_Store within an
>> extension, to process and retrieve a query result, which will be used
>> for something other than printing out the results?
> If you have written am SMW query printer, then you already should
> get a
> result-object in there. I hope that this kind of object is OK for
> your needs,
> since there is no other query result container at the moment. If you
> want to
> get further information (while printing the result?), then there are
> * If you need to exectute an #ask query internally, then you first
> need to
> forge a query object (SMWQuery), which consists of some SMWDescription
> together with some additional parameters. This can be created
> directly by
> building SMWDescription objects as required, or from #ask query syntax
> (slower) by parsing it with SMWQueryProcessor::createQuery(). Once
> you have a
> query object, you can execute this query and retrieve the result. To
> get the
> result object (similar to the one the printer gets), use
> smwfGetStore()->getQueryResult($query). To format such a result with
> existing printer, you can again call some printer's getResult()
> Some combination of those steps (especially combining query
> execution and
> formatting) are implemented in methods of SMWQueryPorcessor, see e.g.
> getResultFromQuery(). Even if those methods are not useful for you,
> might give you the idea how to proceed step by step.
> * If you need just selected information, there are simpler (and much
> ways than issuing an #ask query. Basically, these are the various
> functions in SMWStore (includes/store/SMW_Store.php). You can call
> methods on the object returned by smwfGetStore() in any context.
> Since very recently, SMW in SVN also has a method
> that will retrieve the whole "Factbox" for one page from the store
> in one
> call. If you need to access many properties, this is likely to be
> faster than
> having individual calls for each. For further speed-up, this method
> allows you to supply a simple "filter" array, that instructs the
> store to
> retrieve only certain special properties or only properties of certain
> If this is not what you thought of, some more details on your plans
> would be
>> P.S.: The improvements in 1.0 over 0.7 are terrific so far for
>> extension developers--as I said, making my own ResultPrinter was
>> practically a piece of cake. Thanks again!
> Great that this works for you. Since result printers do really not
> the weight of the software, we are usually happy to add contributed
> to the main distribution (printer registration in extensions, also
> compared to the mechanism for extension datatypes, is still somewhat
>> On Feb 9, 2008, at 7:40 AM, Markus Krötzsch wrote:
>>> On Freitag, 8. Februar 2008, Jeff Thompson wrote:
>>>> Is there a document (or an email message or comments in the code)
>>>> describes the database schema that SMW uses to store semantic data,
>>>> including the change history? I could read the code to try to
>>>> figure it
>>>> out, but I wondered if it is already explained somewhere.
>>> AFAIR it is not. We might add such a resource *but* we strongly
>>> discourage any
>>> direct access to SMW DB tables by extensions anyway. The reason is
>>> that SMW
>>> was designed to allow complete replacement of the semantic storage
>>> implementation with bascially no changes in the SMW code. We might
>>> make us of
>>> that option.
>>> If you want to access semantic data programmatically, consider the
>>> interface methods (SMW_Store.php) if in PHP, and the RDF export
>>> (Special:ExportRDF or full dump via SMW_dumpRDF.php) if you are
>>> outside PHP.
>>> If you need something in between, then subclassing the current MySQL
>>> implementation might be a good idea.
>>>> - Jeff
>>>> - This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> Semediawiki-devel mailing list
>>> Markus Krötzsch
>>> Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
>>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> _____________________________ Semediawiki-devel mailing list
> Markus Krötzsch
> Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998