Re: [SMW-devel] Matrix result formatter
Hi Igor,
On 2011-06-02 07:11, Igor Lobanov wrote:
> I'm looking for a way to produce matrices out of relations between
> arbitrary types of objects/pages in SMW. Simple example would be a
> 'traceability matrix' between pages within such categories as 'Business
> Requirement' and 'System Requirement'. Constructed matrix would have
> business requirements and system requirements as row and column headers
> respectively, while actual elements would be either emply (no
> traceability) or flagged (traceability exists).
>
> Good example is provided in the Wikipedia article:
> http://en.wikipedia.org/wiki/Traceability_matrix
>
> More complex example (one that I have in mind) would be based not on a
> simple relationship, but on internal objects representing relationships
> among various objects with additional scalar properties. In this case,
> cell content would be more flexible and somehow derived from the
> properties, e.g. color, icons, formatting, etc.
>
> Next, I'm able to produce such matrices using a moderately complex
> incantation based on obscure things like arrays and loops, but it's
> O(NxM), needs to be tailored for a particular type of matrix, and look
> awful in general.
>
> I believe that general-purpose matrix/pivot style result formatter for
> inline queries would be good for SMW. Moreover, I'd like to try to blow
> the dust from my PHP skills and actually produce one. What I'm looking
> for is some informed advice on how to approach this one.
>
> My initial idea is to create an extension that introduces a
> {{#pivot...}} instruction that actually does underlying query and
> formatting. Does it make sense? Or it is something that can't be built
> outside the SMW core?
That sounds indeed very useful. I'm just a user of SMW, but I think the
best way to implement this would be as an extension similar to Semantic
Result Formats, or even better, within that extension. It would then not
be a separate parser function, but just an output format, that can be
chosen via the 'format' parameter to an #ask query.
Patrick.
--
Key ID: 0x86E346D4http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4
signature.asc
Description: OpenPGP digital signature
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [SRF], SMW 1.6 (SVN) testing - hashes not getting added to GraphViz file names
Hey, I just had a look at this, and concluded this never could have worked, as the result format appears to reset the GraphViz settings to nothing before creating an actual result since it's first version in the SVN repo. Are you sure graphs worked in this result format before? If so, you found a Schrödinbug :) Anyway, it's fixed now, and should work in the next release. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- On 1 June 2011 22:48, Alex M. Hendler wrote: > Hello, > > I'm not sure if this is worthy of a bug report yet. I'm testing out SMW > 1.6 (r89276) with the latest (r89276-77) versions of SCQ, Semantic > Forms, SIO, and SRF, and the GraphViz extension (r89279), running MW > 1.16.5 on php 5.3.2 (on a 64-bit linux virtual machine if that matters). > > Using SMW 1.5.6 and the latest release (snapshot) versions of the above > extensions on the same machine, graphs would draw just fine - typically > I generate them through a RunQuery form, and I have GraphViz set to > calculate sha1 hashes on the queries, so I would get files in the > images/graphviz directory that look like > > > Special_perc_3ARunQuery_perc_2FFormName--10194d28750c2032a700a37699f10013f6a8a828.map > > and > > > Special_perc_3ARunQuery_perc_2FFormName--10194d28750c2032a700a37699f10013f6a8a828.png > > I have pruning set up, and it works quite well with the extension > snapshots, so after a certain number of graphs get generated (10 on this > installation), they get deleted so that they almost always have the most > up-to-date data. > > Using all the latest SVN versions, I just get > > Special_perc_3ARunQuery---digraph+QueryResult.map > and > Special_perc_3ARunQuery---digraph+QueryResult.png > > The same result persists when accessing the query from outside of a > form, so I'm pretty sure it's not a Semantic Forms issue, for example: > > Test---digraph+QueryResult.map > Test---digraph+QueryResult.png > > The result is that any query from the form results in showing the same > graph, but if I manually clear the images directory between each query, > the graphs show properly to show properly (alternatively, one can > generate graphs from 10 different pages to clear the query, but that's > not very practical); setting pruning at 2 files and an amount of 1 > (essentially, deleting .map and .png pairs as they get created) doesn't > seem to work either. > > Has there been some change in how SMW passes query results to SRF that > won't allow GraphViz to calculate a hash on the query? > > Is there any need for a bug report at this stage, or is it too early to > tell? I'm happy to try to provide a bit more detail in a bug report if > that would be helpful. > > Thanks, > Alex > -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Matrix result formatter
Dear All,
I'm looking for a way to produce matrices out of relations between arbitrary
types of objects/pages in SMW. Simple example would be a 'traceability matrix'
between pages within such categories as 'Business Requirement' and 'System
Requirement'. Constructed matrix would have business requirements and system
requirements as row and column headers respectively, while actual elements
would be either emply (no traceability) or flagged (traceability exists).
Good example is provided in the Wikipedia article:
http://en.wikipedia.org/wiki/Traceability_matrix
More complex example (one that I have in mind) would be based not on a simple
relationship, but on internal objects representing relationships among various
objects with additional scalar properties. In this case, cell content would be
more flexible and somehow derived from the properties, e.g. color, icons,
formatting, etc.
Next, I'm able to produce such matrices using a moderately complex incantation
based on obscure things like arrays and loops, but it's O(NxM), needs to be
tailored for a particular type of matrix, and look awful in general.
I believe that general-purpose matrix/pivot style result formatter for inline
queries would be good for SMW. Moreover, I'd like to try to blow the dust from
my PHP skills and actually produce one. What I'm looking for is some informed
advice on how to approach this one.
My initial idea is to create an extension that introduces a {{#pivot...}}
instruction that actually does underlying query and formatting. Does it make
sense? Or it is something that can't be built outside the SMW core?
--
Best regards,
Igor Lobanov--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] [SRF], SMW 1.6 (SVN) testing - hashes not getting added to GraphViz file names
Hello, I'm not sure if this is worthy of a bug report yet. I'm testing out SMW 1.6 (r89276) with the latest (r89276-77) versions of SCQ, Semantic Forms, SIO, and SRF, and the GraphViz extension (r89279), running MW 1.16.5 on php 5.3.2 (on a 64-bit linux virtual machine if that matters). Using SMW 1.5.6 and the latest release (snapshot) versions of the above extensions on the same machine, graphs would draw just fine - typically I generate them through a RunQuery form, and I have GraphViz set to calculate sha1 hashes on the queries, so I would get files in the images/graphviz directory that look like Special_perc_3ARunQuery_perc_2FFormName--10194d28750c2032a700a37699f10013f6a8a828.map and Special_perc_3ARunQuery_perc_2FFormName--10194d28750c2032a700a37699f10013f6a8a828.png I have pruning set up, and it works quite well with the extension snapshots, so after a certain number of graphs get generated (10 on this installation), they get deleted so that they almost always have the most up-to-date data. Using all the latest SVN versions, I just get Special_perc_3ARunQuery---digraph+QueryResult.map and Special_perc_3ARunQuery---digraph+QueryResult.png The same result persists when accessing the query from outside of a form, so I'm pretty sure it's not a Semantic Forms issue, for example: Test---digraph+QueryResult.map Test---digraph+QueryResult.png The result is that any query from the form results in showing the same graph, but if I manually clear the images directory between each query, the graphs show properly to show properly (alternatively, one can generate graphs from 10 different pages to clear the query, but that's not very practical); setting pruning at 2 files and an amount of 1 (essentially, deleting .map and .png pairs as they get created) doesn't seem to work either. Has there been some change in how SMW passes query results to SRF that won't allow GraphViz to calculate a hash on the query? Is there any need for a bug report at this stage, or is it too early to tell? I'm happy to try to provide a bit more detail in a bug report if that would be helpful. Thanks, Alex -- ontolawgy™ LLC: connect . . . the . . . dots™ http://ontolawgy.com -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SMW 1.6 entering testing phase
On 01/06/11 10:05, zehetner wrote:
> Hi,
>
> for record properties I get from $property->getPropertyTypeID() the type
> __err back
That should not happen. I suppose that your type declaration for such
properties reads "[[has type::Record]]". If this is stored correctly,
you should get the ID '_rec' as a result. This type is no longer handled
in a special way in SMW. so I don't know why it would return an error.
> and this function in includes/datavalues/SMW_DV_Property.php looks
> strange:
>
...
>
> shouldn't it rather be
>
> if ( $this->isValid() ) {
> instead of
> if ( !$this->isValid() ) {
Yes! Changed in SVN now.
Markus
>
> On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
> wrote:
>> On 30/05/11 11:48, zehetner wrote:
>>> Hi,
>>>
>>> I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW
>>> 1.6
>>> alpha r89160)
>>> I updated the DB and data with the SMWAdmin functions. #ask queries
> seem
>>> to work ok.
>>>
>>> I use the calls
>>>
>>> $property = SMWPropertyValue::makeUserProperty($propname);
>>> $ptype = $property->getPropertyTypeID();
>>> where $propname is the name of a property.
>>>
>>> This seems to be valid in SMW 1.6 as it is used e.g. in file
>>> includes/parserhooks/SMW_Declare.php
>>> $property = SMWPropertyValue::makeUserProperty( $propertystring );
>>> :
>>> $type = $property->getPropertyTypeID();
>>>
>>> As far as I can see I run into problems when
>>> function getPropertyTypeID() calls
>>> function getTypesValue() which calls
>>> smwfGetStore()->getPropertyValues( $this->getWikiPageValue(), new
>>> SMWDIProperty( '_TYPE' ) );
>>>
>>> $this->getWikiPageValue() returns a 'SMWWikiPageValue Object' which in
>>> function
>>> getPropertyValues( $subject, SMWDIProperty $property, $requestoptions =
>>> null ) is than passed as '$subject' argument to
>>> $this->getSemanticData( $subject, array(
> $property->findPropertyTypeID()
>>> )
>>> );
>>>
>>> Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject
>>> causes an empty page because it seems it expects
>>> a 'SMWDIWikiPage Object' instead in SMW 1.6?
>>>
>>> getWikiPageValue(), however, seems to return for type _wpg always a
>>> SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object???
>>>
>>> As I only submit a property name in my code and the rest are SMW 1.6
>>> internal functions, I don't know what I can do to avoid this problem.
>>> Anything on the wiki level?
>>
>> Thanks for the report. The code on SVN (r89217) has now been fixed to
>> avoid this problem.
>>
>> Note that SMWPropertyValue::makeUserProperty($propname) should only be
>> used if the input $propname is indeed some (possibly messy) user input.
>> If the name of the property comes from a reliable source, then you can
>> also format it as a DB key (replace ' ' by '_') and use "new
>> SMWDIProeprty($dbkey)" to get an SMWDIProperty object right away (in
>> this case, findPropertyTypeId() is called to get the type id). But for
>> user input SMWPropertyValue is the right way to go.
>>
>> Cheers,
>>
>> Markus
>>
>>
>>>
>>> On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch
>>>wrote:
On 25/05/11 11:20, zehetner wrote:
> Hi,
>
> regarding
>> * Type:Record declarations change:
>> Properties of Type:Record no longer take a list of types, but a list
>>> of
>> properties as their declaration (has fields). This ensures that
>>> Records
>> can use all information that is given on Property pages, not just
> the
>> type declarations.
>
> would there be a foreseeable problem to generate properties with the
>>> name
> of the existing field types e.g Property:string, Property:page,
> Property:number etc. to keep records functioning in the new SMW
>>> version?
> Otherwise having a rather large number of record properties it would
>>> mean
> a lot of typing to change those names in the 'has fields'
> declarations.
I think this is a good idea. Would it be useful to have one builtin
property for each registered datatype? This would not be hard to do
> but
it would override any existing property declarations for these labels.
Generating property pages would be a more complex process that would
need to be triggered explicitly (you cannot do this in the background
> on
>>>
every request).
Regards,
Markus
>
> On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch
> wrote:
>> Dear SMW users and developers,
>>
>> work on SMW 1.6 has made tremendous progress in the past few weeks,
>>> and
>> the code is stabilizing now. We still have quite some bugs to fix
>>> ahead
>> of us, but the main changes in architecture and user features are
>> completed.
>>
>> If they have not done it yet, extension developers should now adapt
>> their code to work with the modified APIs. Audacious users are
> invited
>> to beta test. Installation instructio
Re: [SMW-devel] SMW 1.6 entering testing phase
Hi,
for record properties I get from $property->getPropertyTypeID() the type
__err back
and this function in includes/datavalues/SMW_DV_Property.php looks
strange:
/**
* Convenience method to find the type id of this property. Most
callers
* should rather use SMWDIProperty::findPropertyTypeId() directly.
Note
* that this is not the same as getTypeID(), which returns the id
of
* this property datavalue.
*
* @return string
*/
public function getPropertyTypeID() {
if ( !$this->isValid() ) {
return $this->m_dataitem->findPropertyTypeId();
} else {
return '__err';
}
}
shouldn't it rather be
if ( $this->isValid() ) {
instead of
if ( !$this->isValid() ) {
Gu
On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
wrote:
> On 30/05/11 11:48, zehetner wrote:
>> Hi,
>>
>> I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW
>> 1.6
>> alpha r89160)
>> I updated the DB and data with the SMWAdmin functions. #ask queries
seem
>> to work ok.
>>
>> I use the calls
>>
>> $property = SMWPropertyValue::makeUserProperty($propname);
>> $ptype = $property->getPropertyTypeID();
>> where $propname is the name of a property.
>>
>> This seems to be valid in SMW 1.6 as it is used e.g. in file
>> includes/parserhooks/SMW_Declare.php
>> $property = SMWPropertyValue::makeUserProperty( $propertystring );
>> :
>> $type = $property->getPropertyTypeID();
>>
>> As far as I can see I run into problems when
>> function getPropertyTypeID() calls
>> function getTypesValue() which calls
>> smwfGetStore()->getPropertyValues( $this->getWikiPageValue(), new
>> SMWDIProperty( '_TYPE' ) );
>>
>> $this->getWikiPageValue() returns a 'SMWWikiPageValue Object' which in
>> function
>> getPropertyValues( $subject, SMWDIProperty $property, $requestoptions =
>> null ) is than passed as '$subject' argument to
>> $this->getSemanticData( $subject, array(
$property->findPropertyTypeID()
>> )
>> );
>>
>> Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject
>> causes an empty page because it seems it expects
>> a 'SMWDIWikiPage Object' instead in SMW 1.6?
>>
>> getWikiPageValue(), however, seems to return for type _wpg always a
>> SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object???
>>
>> As I only submit a property name in my code and the rest are SMW 1.6
>> internal functions, I don't know what I can do to avoid this problem.
>> Anything on the wiki level?
>
> Thanks for the report. The code on SVN (r89217) has now been fixed to
> avoid this problem.
>
> Note that SMWPropertyValue::makeUserProperty($propname) should only be
> used if the input $propname is indeed some (possibly messy) user input.
> If the name of the property comes from a reliable source, then you can
> also format it as a DB key (replace ' ' by '_') and use "new
> SMWDIProeprty($dbkey)" to get an SMWDIProperty object right away (in
> this case, findPropertyTypeId() is called to get the type id). But for
> user input SMWPropertyValue is the right way to go.
>
> Cheers,
>
> Markus
>
>
>>
>> On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch
>> wrote:
>>> On 25/05/11 11:20, zehetner wrote:
Hi,
regarding
> * Type:Record declarations change:
> Properties of Type:Record no longer take a list of types, but a list
>> of
> properties as their declaration (has fields). This ensures that
>> Records
> can use all information that is given on Property pages, not just
the
> type declarations.
would there be a foreseeable problem to generate properties with the
>> name
of the existing field types e.g Property:string, Property:page,
Property:number etc. to keep records functioning in the new SMW
>> version?
Otherwise having a rather large number of record properties it would
>> mean
a lot of typing to change those names in the 'has fields'
declarations.
>>>
>>> I think this is a good idea. Would it be useful to have one builtin
>>> property for each registered datatype? This would not be hard to do
but
>>> it would override any existing property declarations for these labels.
>>>
>>> Generating property pages would be a more complex process that would
>>> need to be triggered explicitly (you cannot do this in the background
on
>>
>>> every request).
>>>
>>> Regards,
>>>
>>> Markus
>>>
On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch
wrote:
> Dear SMW users and developers,
>
> work on SMW 1.6 has made tremendous progress in the past few weeks,
>> and
> the code is stabilizing now. We still have quite some bugs to fix
>> ahead
> of us, but the main changes in architecture and user features are
> completed.
>
> If they have not done it yet, extension developers should now adapt
> their code to work with the mo
Re: [SMW-devel] SMW 1.6 entering testing phase
Thanks Markus, this problem has disappeared now! Cheers, Gu On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch wrote: > On 30/05/11 11:48, zehetner wrote: >> Hi, >> >> I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW >> 1.6 >> alpha r89160) >> I updated the DB and data with the SMWAdmin functions. #ask queries seem >> to work ok. >> >> I use the calls >> >> $property = SMWPropertyValue::makeUserProperty($propname); >> $ptype = $property->getPropertyTypeID(); >> where $propname is the name of a property. >> >> This seems to be valid in SMW 1.6 as it is used e.g. in file >> includes/parserhooks/SMW_Declare.php >> $property = SMWPropertyValue::makeUserProperty( $propertystring ); >> : >> $type = $property->getPropertyTypeID(); >> >> As far as I can see I run into problems when >> function getPropertyTypeID() calls >> function getTypesValue() which calls >> smwfGetStore()->getPropertyValues( $this->getWikiPageValue(), new >> SMWDIProperty( '_TYPE' ) ); >> >> $this->getWikiPageValue() returns a 'SMWWikiPageValue Object' which in >> function >> getPropertyValues( $subject, SMWDIProperty $property, $requestoptions = >> null ) is than passed as '$subject' argument to >> $this->getSemanticData( $subject, array( $property->findPropertyTypeID() >> ) >> ); >> >> Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject >> causes an empty page because it seems it expects >> a 'SMWDIWikiPage Object' instead in SMW 1.6? >> >> getWikiPageValue(), however, seems to return for type _wpg always a >> SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object??? >> >> As I only submit a property name in my code and the rest are SMW 1.6 >> internal functions, I don't know what I can do to avoid this problem. >> Anything on the wiki level? > > Thanks for the report. The code on SVN (r89217) has now been fixed to > avoid this problem. > > Note that SMWPropertyValue::makeUserProperty($propname) should only be > used if the input $propname is indeed some (possibly messy) user input. > If the name of the property comes from a reliable source, then you can > also format it as a DB key (replace ' ' by '_') and use "new > SMWDIProeprty($dbkey)" to get an SMWDIProperty object right away (in > this case, findPropertyTypeId() is called to get the type id). But for > user input SMWPropertyValue is the right way to go. > > Cheers, > > Markus > > >> >> On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch >> wrote: >>> On 25/05/11 11:20, zehetner wrote: Hi, regarding > * Type:Record declarations change: > Properties of Type:Record no longer take a list of types, but a list >> of > properties as their declaration (has fields). This ensures that >> Records > can use all information that is given on Property pages, not just the > type declarations. would there be a foreseeable problem to generate properties with the >> name of the existing field types e.g Property:string, Property:page, Property:number etc. to keep records functioning in the new SMW >> version? Otherwise having a rather large number of record properties it would >> mean a lot of typing to change those names in the 'has fields' declarations. >>> >>> I think this is a good idea. Would it be useful to have one builtin >>> property for each registered datatype? This would not be hard to do but >>> it would override any existing property declarations for these labels. >>> >>> Generating property pages would be a more complex process that would >>> need to be triggered explicitly (you cannot do this in the background on >> >>> every request). >>> >>> Regards, >>> >>> Markus >>> On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch wrote: > Dear SMW users and developers, > > work on SMW 1.6 has made tremendous progress in the past few weeks, >> and > the code is stabilizing now. We still have quite some bugs to fix >> ahead > of us, but the main changes in architecture and user features are > completed. > > If they have not done it yet, extension developers should now adapt > their code to work with the modified APIs. Audacious users are invited > to beta test. Installation instructions are online [1] and the SMW > Sandbox is updated to the most recent version [2]. > > == Main changes for users == > > * Significantly extended database backend support: > SMW now works with PostgreSQL and with any RDF store that supports > SPARQL and SPARQL Update. I had sent details about the latter to this > list earlier -- testers for Virtuoso and other stores would still be > most welcome! Support for using the PHP-based interface of the RAP RDF > store is discontinued. The new SPARQL functions change also prepare >> SMW > for loading RDF data from other Web sources (not implemented yet). > > * Parameter validation for user inputs: > The #ask function will now genera
