Sergey,

Also, I wonder if you're going to extend Semantic Forms with data entry tool as well.

Yes, definitely planning on it. First, though, I'm planning on implementing a pluggable AJAXy search function, for geocoding, Google search, etc. That way, in SF, you can get a map, search for a place or address, then pick the right one from the map--perfect for SF. 

-Matt


On Mar 16, 2008, at 10:05 PM, Sergey Chernyshev wrote:

Matt, it's great to hear that you're planning on getting SemLayers up to date with SMW - I'm definitely thinking about more map-based querying for my TechPresentations.org and want to start collecting full venue addresses for events to enable better map views.

Also, I wonder if you're going to extend Semantic Forms with data entry tool as well.

          Sergey


On Sun, Mar 16, 2008 at 2:22 PM, Matt Williamson <matthewdw@gmail.com> 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. Good to
know there's a fast vs.slow way to do it, too. 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)?

> 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. 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
>>>> Semediawiki-devel@lists.sourceforge.net
>>>> 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
>>> mak@aifb.uni-karlsruhe.de          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
>>> Semediawiki-devel@lists.sourceforge.net
>>> 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
> mak@aifb.uni-karlsruhe.de          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
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



--
Sergey Chernyshev
http://www.sergeychernyshev.com/