On Sonntag, 16. März 2008, Matt Williamson wrote: > Markus, > > Thanks! > > > * 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 > > an > > existing printer, you can again call some printer's getResult() > > method. > > This sounds perfect! The SMWStore->getQueryResult() part was the bit I > was missing, I think--plus exactly how to create the SMWQuery.
Bascially you do
new SMWQuery($some_smw_description)
and set query parameters such as "limit" on the resulting query object.
The object $some_smw_description is an API encoding of the query conditions.
The available descriptions are the intances of the classes in
SMW_Description.php. For example, an SMWClassDescription object queries for
all objects in a certain category, and an SMWSomeProperty encodes a query for
a property of a certain value. For instance, the query
{{#ask:[[some_property::some_value]] }}
can be encoded as follows:
$prop_title = Title::makeTitle(SMW_NS_PROPERTY, "some_property");
$prop_value =
SMWDataValueFactory::newPropertyValue("some_property", "some_value");
$value_desc = new SMWValueDescription($prop_value);
$desc = new SMWSomeProperty($prop_title, $value_desc);
$query = new SMWQuery($desc);
$desc is the final description of the query: a some-property-description for
property $prop_title, restricted to values that fit $value_desc. $value_desc
in turn matches only the value "some_value" (or the SMWDataValue object built
for "some_property" when users enter that string). One can also create
SMWValueDescriptions that use some comparator as documented in
SMW_Description.php, e.g.
$value_desc = new SMWValueDescription($prop_value, SMW_CMP_LEQ);
If you know that datatype of the property, you can also create the value
directly from SMWDataValueFactory::newTypeIDValue, as e.g. in
$prop_value = SMWDataValueFactory::newTypeIDValue("_wpg", "some_value");
(the internal type ids like "_wpg" have a fixed mapping to SMW datatypes and
can savely be reused, the mapping is found in the langauge files). More
complex descriptions can be built from simple ones. For example,
SMWDescriptions of class SMWConjunction take an array of description objects,
and will only match the objects that fit all the descriptions (logical AND).
Reading the comments on the classes in SMW_Description.php is probably the
best way of getting an overview.
Descriptions also contain print requests, i.e. the additional printout
statents that generate all but the first column in a result table. Those are
simpler objects of class SMWPrintRequest that can be added with
addPrintRequest to the final description. Print requests for sub-descriptions
are discouraged (their processing might change in the future).
If you build very complex descriptions, the query object might prune your
description according to site restrictions (e.g. one can limit the breadth
and depth of the query with global parameters). In this case, and in other
cases where problems occur, the query result will again contain an array of
error strings that one can output to inform the user of possible problems.
> Good to
> know there's a fast vs.slow way to do it, too.
Building larger descriptions in a hard-coded way thus requires some lines of
code. But it is of course faster than letting SMW use its generic query
string parser (all the parsing is saved). Not sure how much impact that would
have.
> The result object is
> exactly what I need, I just hadn't figured out how to get one outside
> the context of a ResultPrinter.
>
> > * If you need just selected information, there are simpler (and much
> > faster)
> > ways than issuing an #ask query. Basically, these are the various
> > get...
> > functions in SMWStore (includes/store/SMW_Store.php). You can call
> > those
> > methods on the object returned by smwfGetStore() in any context.
>
> Yes, I noticed the methods like getPropertyValues and
> getPropertySubjects and those will definitely be useful in several
> cases. Question: in that object's code comments, is a "subject" the
> same thing as a page or sub-page? It looks like it, but I'm not 100%
> sure. If not, what are the differences (or do I have it wrong entirely)?
A "subject" is anything that a semantic statement refers to, i.e. currently
always a wiki page. Subjects currently are almost always encoded as Title
objects (the exception should be the query result). In some future, subjects
will become SMWWikiPageValue objects, and there might also be a better API
representation for properties (also encoded by Title objects right now).
>
> > Since very recently, SMW in SVN also has a method
> > SMWStore::getSemanticData()
> > 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
> > also
> > allows you to supply a simple "filter" array, that instructs the
> > store to
> > retrieve only certain special properties or only properties of certain
> > datatypes.
>
> Really? That's excellent...any idea when this will make it into the
> stable release? That would certainly speed up at least a few cases.
> But I'm figuring I'd better target a stable release for now.
I will very soon release a new minor update SMW1.0.2, also to fully comply
with MW1.12. This update will include the new method. So it is probably a
good idea to build on that new method right away.
Regards,
Markus
> This
> would be perfect for retrieving the properties of a Layer in my
> extension (marker icon, offset parameters, dimensions, etc.). Anyway,
> I should be able to accomplish this without it, but I'll definitely
> keep that in mind for future optimization.
>
> Thanks again!
>
> -Matt
>
> On Mar 16, 2008, at 1:52 PM, Markus Krötzsch wrote:
> > On Samstag, 15. März 2008, Matt Williamson wrote:
> >> Markus,
> >>
> >> 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
> > applications.
> >
> >> 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
> >> you
> >> 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
> > several
> > options:
> >
> > * 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
> > an
> > existing printer, you can again call some printer's getResult()
> > method.
> >
> > 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,
> > they
> > might give you the idea how to proceed step by step.
> >
> > * If you need just selected information, there are simpler (and much
> > faster)
> > ways than issuing an #ask query. Basically, these are the various
> > get...
> > functions in SMWStore (includes/store/SMW_Store.php). You can call
> > those
> > methods on the object returned by smwfGetStore() in any context.
> >
> > Since very recently, SMW in SVN also has a method
> > SMWStore::getSemanticData()
> > 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
> > also
> > allows you to supply a simple "filter" array, that instructs the
> > store to
> > retrieve only certain special properties or only properties of certain
> > datatypes.
> >
> >
> > If this is not what you thought of, some more details on your plans
> > would be
> > useful.
> >
> > Regards,
> >
> > Markus
> >
> >> Thanks!
> >>
> >> -Matt
> >>
> >> 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
> > increase
> > the weight of the software, we are usually happy to add contributed
> > printers
> > to the main distribution (printer registration in extensions, also
> > when
> > compared to the mechanism for extension datatypes, is still somewhat
> > under-developed).
> >
> >> 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)
> >>>> that
> >>>> 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
> >>> storage
> >>> 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
> >>> storage
> >>> implementation might be a good idea.
> >>>
> >>> Cheers,
> >>>
> >>> Markus
> >>>
> >>>> Thanks,
> >>>> - Jeff
> >>>>
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>-- - This SF.net email is sponsored by: Microsoft
> >>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>>> _______________________________________________
> >>>> Semediawiki-devel mailing list
> >>>> [email protected]
> >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >>>
> >>> --
> >>> Markus Krötzsch
> >>> Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
> >>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
> >>> [EMAIL PROTECTED] www http://korrekt.org
> >>> -----------------------------------------------------------------------
> >>>-- This SF.net email is sponsored by: Microsoft
> >>> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/________________
> >>>__ _____________________________ Semediawiki-devel mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> > --
> > Markus Krötzsch
> > Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
> > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
> > [EMAIL PROTECTED] www http://korrekt.org
--
Markus Krötzsch
Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
[EMAIL PROTECTED] www http://korrekt.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Semediawiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
