Re: [SMW-devel] Is SMW 1.6.2 released?

[badon]

Will image queries be fixed in 1.6.2? They were broken in 1.6.1, so actually
1.6.0 is the last version that was fully functional. See this bug:

https://bugzilla.wikimedia.org/show_bug.cgi?id=30494




Markus Krötzsch-2 wrote:
> 
> On 29/09/11 13:05, Toni Hermoso Pulido wrote:
>> Hello,
>>
>> I was checking http://semantic-mediawiki.org/ and current version
>> number is 1.6.2, but it doesn't appear here:
>> http://sourceforge.net/projects/semediawiki/files/semediawiki/
> 
> SMW 1.6.2 provides a few bugfixes that we wanted to make available, but 
> it also did some internal changes in parameter handling that have been 
> found to cause new incompatibilities. Therefore, we decided to 
> discourage the use of SMW 1.6.2 for now and keep SMW 1.6.1 as the main 
> download package.
> 
> We plan to release an update sometime soon that completes the transition 
> to the new parameter handling system (remaining incompatible where it is 
> now, but in a decisive way ;-).
> 
> Regards,
> 
> Markus
> 
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> ___
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Is-SMW-1.6.2-released--tp32561550p32746007.html
Sent from the Semantic Mediawiki - Development mailing list archive at 
Nabble.com.


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] Recommended way to use WOM from other extensions?

[Jesse Wang]

Hi, Samuel,
Just got a chance to write back, I've busy dealing with jet lag and trick or
treat :-)
For developers, the recommended way is to use the WOM Functions directly
because you have more control and it'll be faster too.
I'm not sure what caused the error you mentioned, can you send me and Ning
(cc-ed here too) more details about the repro of the issue (such as your
browser version, OS, etc.)?
Have a good weekend!
Jesse

On Fri, Oct 28, 2011 at 12:42 PM, Samuel Lampa wrote:

> Hi Jesse (cc SMW-devel, if someone else has some input),
>
> I'm looking into using the WOM extension in RDFIO.
>
> I was wondering what the recommended way is to access the WOM API from
> other extensions ... Is it via the API functions (described in
> http://wiking.vulcan.com/dev/**index.php/Extension:Wiki_**
> Object_Model/Apis),
>  for example via fauxRequest, or by using the WOMProcessor and related
> functions directly (as seen in http://wiking.vulcan.com/dev/**
> index.php/Extension:Wiki_**Object_Model/Functions#WOM_**Functions)?
>
> I guess both might work(?), but I was looking for the pros/cons of each,
> and any other hints?
>
> Cheers,
> // Samuel
>
> --
> Samuel Lampa
> --**-
>  Bioinformatician @ Uppsala University
>   Blog: http://saml.rilspace.org
> --**-
>
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

[SMW-devel] Update your code: changes in display of wiki pages

[Markus Krötzsch]

In the cause of adding the new display features for subobjects, I have 
also done some modifications to the display methods for SMWWikiPageValue 
that affects how page names are presented to the user. You may want to 
update some code to get the desired display with the new version. Below 
are the details.

== getShort*Text and getLong*Text ==

The "Short" methods used to return the page name with full namespace 
prefix by default if no other caption was given. The "Long" versions, in 
contrast, used to abbreviate labels if a link was given anyway (so one 
could get a link to "User:Foo" that was simply labelled with "Foo"; the 
rationale was that the information is in the link anyway). So the 
"Short*" methods returned the longer text versions than the "Long*" ones.

Now this has been fixed. The default for Short is to abbreviate labels 
in links while the default for Long is to show all details even in link 
labels. There was extra code to use the opposite method in case of wiki 
pages, e.g., in SMWQueryResult. This is all simplified now. As usual, 
only Short* methods use the caption (if set).

So it should be pretty obvious what to call if you want longer or 
shorter texts. Code that expects the old behaviour will still work, but 
will display more/less namespace prefixes than desired.

Note that only linked displays are affected. Unlinked versions will 
always include prefixes.

== Image: values ==

Some changes were made to the display of images:

* [[property::Image:Foo|some|image|settings]] will now display like 
[[Image:Foo|some|image|settings]] as one would expect
* images in query results will *only* show the image, no additional line 
breaks or links

== Wiki value ==

The wiki value never includes an initial ":", not even for values like 
"Category:Foo". So if you use getWikiValue() somewhere to put it into 
[[...]], you may want to add an initial ":" to escape this (or maybe you 
want to use get*WikiText() instead).

== Fragments/Subobjects ==

Fragments are usually displayed by all functions since they are 
important to distinguish different objects. They appear as post-fixes 
"#fragment" after the title. Only if a fragment starts with "_" it will 
not be displayed in links since this is used to refer to internal 
subobject identifiers that make no sense to humans. But getWikiValue() 
and all non-linked displays always include the fragment.


Cheers,

Markus


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Markus Krötzsch]

Updates on the "subobject" feature. The following changes have now been 
implemented and committed to SVN.


== Parser function #subobject ==

The new parser function #subobject can be used to create *named* 
subobjects. Example:

{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}

creates a new subobject with four property values. If this is done on a 
page called "Testpage" then the subobject is named 
"Testpage#My_office_address" and it can be used under that name 
everywhere in the wiki. Example:

[[has office address::Testpage#My_office_address]]

You can use space " " instead of underscore "_" as they are equivalent 
in fragments (in MediaWiki) and in subobject names (in SMW). However, 
note that fragment names are strictly case sensitive, even in the fist 
letter. So "my office address" is not the same as "My office address".

To have a property from the subobject to the parent page (like in the 
SIO extension) simply add such a property to the data. Example:

{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
| is address of=Markus Kroetzsch
}}

on the page "Markus Kroetzsch".

The #subobject parser function is completely silent and returns no text 
unless errors occur. If errors happen, then they are shown in the place 
where the parser function is used.


== Fragment support for wiki page values ==

As indicated above, all wiki page property values can now have 
fragments. They will be stored faithfully and be part of the meaning of 
a value. Different fragment names encode different values.

You can also use the MediaWiki shortcut for fragments of the page you 
are one. Example:

[[has office address::#My office address]]

on the page "Testpage" has the same meaning as [[has office 
address::Testpage#My office address]]. This makes it easier to link to 
subobjects too.


== Interaction with subobjects ==

Subobjects work like pages in all interfaces (they are represented in 
the same datastructure internally, so all existing code will work with 
them if it works with pages now).

All subobjects of a page that are created with #subobject are assigned 
to the new predefined property "Has subobject". This can be used to 
query for all subobjects and to show them on pages like Special:Browse 
even if they are not otherwise linked to anything.


Cheers,

Markus

P.S. I have also adjusted the display of page names in SMW in general as 
part of the inclusion of subobjects. This may affect some displays, 
especially if the change was not propagated to all places in SMW. I will 
send another email to the devleoper list to explain the details to other 
devs. Let me know if you discover any display problems with page names.


On 03/10/11 10:02, Markus Krötzsch wrote:
> Following up the discussions we had at SMWCon in Berlin, we have now
> implemented a new feature for "internal objects" in SMW. This email
> explains this feature and starts the discussion on some open questions
> for it to become stable.
>
>
> == Goal ==
>
> Allow SMW annotations to refer to objects that have their own
> property-value pairs just like wiki pages, but that do not actually have
> an article in the wiki. This can be used to "group" property-value pairs
> given on one page without requiring new auxiliary pages to be created.
> It also integrates the main functionality of the Semantic Internal
> Objects (SIO) extension into SMW.
>
>
> == Feature Overview: Current Prototype Implementation ==
>
> SMW now has a new "subobject" feature. For example, you can use the
> parserfunction #subobject on some page "Example page" as follows:
>
> {{#subobject:street address
> | street name=Parks Road
> | postcode=OX1 3QD
> | city=Oxford
> | country=UK
> }}
>
> This does the following:
>
> (A) create a new subobject called "Example page#_anInternalId",
> (B) assign the property values for "street name", ..., "country" to this
> subobject,
> (C) assign the subobject "Example page#_anInternalId" as a property
> value for "street address" to "Example page".
>
> You could have achieved a similar effect as follows:
>
> (A') create a new page called "my auxiliary page",
> (B') edit this new page to contain the text:
>
>[[street name::Parks Road]]
>[[postcode::OX1 3QD]]
>[[city::Oxford]]
>[[country::UK]]
>
> (C') edit the page "Example page" to contain the text:
>
>[[street address::my auxiliary page]]
>
>
> The difference when using #subobject is that you do not create a new
> auxiliary page. Instead, a subobject of "Example page" is created by
> SMW. Also, the function #subobject does not display anything unless an
> error occurred that needs to be reported.
>
> Subobjects are named automatically by following the schema "Parent page
> name#_someInternalId". When subobjects are displayed to users, they thus
> appear like links to sections within their parent page. This can happen,
> e.g., subobjects might occur in query results

Re: [SMW-devel] New way to format tabular results?

[Dan Bolser]

I like this idea too. However, I suspect it will be hard to get MW to
ignore {{{#n}}} just for the purposes of SMW.

Is there a cleaner way to 'inline' a format template in the query?

I totally agree that creating two or three templates for one ask query
is the main reason that template format is a pain.


Cheers,
Dan.

On 28 October 2011 23:18, Jon Lang  wrote:
> Dan Bolser wrote:
>>
>> Hi,
>>
>> Currently we have tabular format results and, if we want
>> customization, we have 'template' format results.
>> * Tabular format is great, but is quite inflexible.
>> * Template format is very flexible, but complex, hard to develop and
>> maintain.
>>
>> I'd like to suggest a half way house for simple column based tabular
>> formatting. Something along the lines of the following:
>>
>> {{#ask: [[My Cat]]
>>  |? My prop 1 # Template for p1
>>  |? My prop 2 # Template for p2
>>  |? My prop 3
>>  |? My prop 4 = P4
>> }}
>>
>> For each row, this would call the template 'Template for p1' with just
>> one parameter, the value for 'My prop 1'. The resulting wikitext would
>> then be passed back for regular tabular layout. As implied, these 'per
>> column' templates could be mixed with 'unadorned' values, that would
>> appear just as in regular tabular output.
>>
>> This would be a much lighter and easier way to 'tweak' the results of
>> tabular format without going to the full blown (and sometimes
>> unpopular) template format.
>>
>> I've posted here for discussion, but we can start a feature request
>> instead.
>>
>
> I like this idea, and would like to piggyback a suggestion of my own here.
>
> Sometimes, the reason why the template format is unpopular is because it is
> overkill.  For instance, if you're only going to be formatting a single
> #ask, creating a full template page for it seems like a bit much.  I'd like
> to see an "inline" result format that works just like the template result
> format except that it embeds the template directly into the query.  For
> example:
>
> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>   | ?Population=Inhabitants
>   | ?Area#km²=Size in km²
>   | format=inline
>   | inline={{{#2}}} people squeeze into the {{{#3}}} of {{{#1}}}.
>   | limit=3
> }}
>
> The hash marks inside the triple-curlies are to distinguish these "inline
> template" parameters from any regular template parameters that may be in
> play if the #ask appears on a template page.
>
> This is germane to Dan's proposal in that I would recommend inline templates
> for what he's suggesting rather than regular templates:
>
> {{#ask: [[My Cat]]
>   |? My prop 1 # format string for p1
>   |? My prop 2 # format string for p2
>   |? My prop 3
>   |? My prop 4 = P4
> }}
>
> As with my "inline result format" suggestion above, the value for each
> cell's format would be specified as {{{#1}}}.  So:
>
> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>   | ?Population=Inhabitants # {{{#1}}} people
>   | ?Area#km²=Size in km²
>   | limit=3
> }}
>
> would produce something like:
>
> {|
> ! Inhabitants !! Size in km²
> |-
> | Berlin || 3,391,409 people || 891.85 km²
> |-
> | Frankfurt || 679,664 people || 248.31 km²
> |-
> | Karlsruhe || 285,812 people || 173.46 km²
> |}
>
> If you wish to utilize an actual template page, you can do so using the
> regular wiki syntax for including a template; the only catch is that I think
> that you'd have to explicitly pass the value into the template:
>
> {{#ask: [[My Cat]]
>   |? My prop 1 # {{template for p1|{{{#1}
>   |? My prop 2 # {{template for p2|{{{#1}
>   |? My prop 3
>   |? My prop 4 = P4
> }}
>
> --
> Jonathan "Dataweaver" Lang
>

--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel