Re: [SMW-devel] SMW 1.6 entering testing phase
On 22 May 2011 16:10, Markus Krötzsch wrote: > Dear SMW users and developers, > > work on SMW 1.6 has made tremendous progress in the past few weeks > == 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 I can't seem to find that email. Can you direct me to it? I'm keen to know more about the new SPARQL endpoint support, as I think this is very exciting. > 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). Since SMW is now processing SPARQL / RDF internally (I'm guessing), does this mean that we can (in theory?) query a given endpoint using #ask? I'm curious if this would require synchronization of the data in the endpoint (as some docs seem to suggest), or if ad-hock endpoints can now be queried using #ask. Thanks for all the great and continuing work on this project! Dan. -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ 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 09/06/11 14:48, zehetner wrote:
> Hi,
>
> I have another question. I use
>
> $addpropa =
> $store->getPropertyValues($this->subject->getTitle(),SMWPropertyValue::makeUserProperty($propertyname));
>
>
> in SMW 1.6 I assume I need to use
>
> SMWPropertyValue::makeProperty($propertyid)
>
> instead of
>
> SMWPropertyValue::makeUserProperty($propertyname)
>
> in order to pass now a SMWDIProperty object instead of a SMWPropertyValue
> object to $store->getPropertyValues()
>
>
> How to I get the propertyid from the propertyname or
> get a SMWDIProperty object if I have the propertyname or
> how do I convert a SMWPropertyValue object to a SMWDIProperty object?
All DV objects give you the according DI by calling getDataItem(). This
is in general what you do in places where you might have called
getDBkeys() in the past; it is the main way of accessing the actual data
(as opposed to formatting the data for various outputs, which is not
done by DIs).
If you have messy inputs (user-written text etc.) then the only way of
getting a proper DI is to invoke the DV with setUserValue() as usual (or
use one of the static methods of SMWPropertyValue as before).
But if you have reasonably clean property names/keys at hand, then you
can use SMWDIProperty::newFromUserLabel() to get the right property
immediately.
If you do not have a label but even an internal key ("My_user_property"
or "_MDAT"; but never a user-labelish key like "Modification_date" for a
special property like "_MDAT") then you can also just create the
property yourself: "new SMWDIProperty( $key );" This is mainly useful
when creating special properties from their internal keys.
Cheers,
Markus
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
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
Thanks Markus!
Sorry if I didn't make it clear, the reason why I got __err back was the
erroneous '!' in the mentioned function (although I'm now not sure why none
record properties seemed to work even with the bug?).
Anyway in the corrected version all work fine.
Cheers,
Gu
On Wed, 01 Jun 2011 17:14:26 +0100, Markus Krötzsch
wrote:
> 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
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
Re: [SMW-devel] SMW 1.6 entering testing phase
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 generate more helpful error messages if > some input is not suitable, e.g. if "limit" is set to "bogus" instead of a number. Query printers may also use this capability for their own parameters, so that even extensions can provide this validation. For doing t
Re: [SMW-devel] SMW 1.6 entering testing phase
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, Gu 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 generate more helpful error messages if some >>> input is not suitable, e.g. if "limit" is set to "bogus" instead of a >>> number. Query printers may also use this capability for their own >>> parameters, so that even extensions can provide this validation. For >>> doing this, SMW requires the Validator extension to be installed. >>> >>> * No more "Type" namespace: >>> As discussed on these lists, the Type namespace has been removed. There >> >>> is a configuration setting that allows users to keep the Type namespace >>> enabled (so that any pages there can still be accessed). The features of >> >>> Type articles are now provided by Special:Types. >>> >>> * New Delimited-Separated Values format: >>> This is like CSV but with a sane and easy-to-parse escaping of special >>> characters. >>> >>> * Unit of measurement declarations change: >>> With the vanishing of Type pages, users who have used custom types (for >>> unit conversion) must move the text from the Type page to the Property >>> page that uses these cus
[SMW-devel] SMW 1.6 entering testing phase
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 generate more helpful error messages if some input is not suitable, e.g. if "limit" is set to "bogus" instead of a number. Query printers may also use this capability for their own parameters, so that even extensions can provide this validation. For doing this, SMW requires the Validator extension to be installed. * No more "Type" namespace: As discussed on these lists, the Type namespace has been removed. There is a configuration setting that allows users to keep the Type namespace enabled (so that any pages there can still be accessed). The features of Type articles are now provided by Special:Types. * New Delimited-Separated Values format: This is like CSV but with a sane and easy-to-parse escaping of special characters. * Unit of measurement declarations change: With the vanishing of Type pages, users who have used custom types (for unit conversion) must move the text from the Type page to the Property page that uses these custom types. Instead of the custom type page, "has type" is now set to "Quantity" for properties that have custom unit conversions. * 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. * Compatibility with MediaWiki 1.18. * Bugfixes. == Main changes for developers == There have been substantial changes to the data model: almost all uses of SMWDataValue have been replaced by more lightweight SMWDataItem objects. Code has been cleaned up in the process and should be much clearer to understand in many places (also beyond the data item changes). See my earlier email to the developer list for details. Please ask on the developer list if you should encounter any problems updating your code to work with SMW 1.6. SMW 1.6 is an important major release for us, and a unique opportunity to do some changes that are not fully compatible with earlier versions (but that really improve the overall functionality and code quality). If you have comments or bug reports, it is a very good time to make them known. Some things will be much harder to change later on. We intend to stabilize SMW within the next 14 days, so that a first release of SMW 1.6 could happen in early June. Thanks to all who have already contributed to this major effort, and to all who are currently working hard on upgrading their code to SMW 1.6. Cheers, Markus [1] http://semantic-mediawiki.org/wiki/Help:Installation_1.6.0 [2] http://sandbox.semantic-mediawiki.org/ -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
