semediawiki-devel — Discussions among developers of SMW and its extensions

[SMW-devel] coding: TypeHandlers and OldDataValue

[S P. <in...@sk...>]

I wrote code to support specifying the sort order of enumerations, much 
like Ittay Dror originally proposed:

  [[allows value::Enhancement=-1]]
  [[allows value::Trivial=0]]
  [[allows value::Minor=3]], etc.

But I wonder about the status of DT_Enum.php.  The newer datatypes 
extend SMWDataValue, while the old type handlers rely on creating 
instances of SMWOldDataValue with a comment "///TODO migrate to new system".

Markus, are you intending to convert all the SMW_DT types?  If so, I 
have a patch for Enum that migrates it to DataValue and another patch 
that adds the ordering enhancement.

--
=S Page

Re: [SMW-devel] Semantic link for citations

[Jeff T. <je...@th...>]

Markus Krötzsch wrote:
> As a general answer: we currently do not consider a feature for adding 
> citations to semantic facts, and I think it is not yet clear how this should 
> best be done in general. If some concrete plans for doing this emerge here, 
> we could consider this after SMW1.0

The best evidence for whether we need semantic citations will come when we
see if Wikipedia authors really start using semantic markup.  How soon after
the SMW1.0 release will Wikipedia enable it?

Re: [SMW-devel] SMW_unifyProperties.php and Re: [Semediawiki-user] A note on using SMW SVN

[Markus <ma...@ai...>]

On Dienstag, 2. Oktober 2007, S Page wrote:
> Markus Kr=F6tzsch wrote:
> > * (maintenance script) SMW_refreshData.php
>
> There's another maintenance script, SMW_unifyProperties.php.  It move
> all pages in the Relation namespace to new pages in the Property
> namespace.  (The Attribute namespace becomes the Property namespace in
> SMW 1.0, so attribute pages become property pages automatically.)  When
> I ran SMW_unifyProperties.php:
>
>    Checking if properties need to be unified
>    Unification is required. 9 relation pages need to be moved.
>    1 conflicts have been detected.
>    Please unify these conflicts manually.
>    Moving 8 pages now.
>    Unify properties script done.
>
> After this all my Relation pages were #REDIRECTs to Property pages,
> except for the one conflict, a Relation:Climate page that conflicts with
> my former Attribute:Climate page.
>
> The script works and seems useful, so I documented it in
> http://ontoworld.org/wiki/Upgrading_from_SMW_0.7_to_SMW_1.0

Nice. The script is still somewhat experimental. Good to see that it works =
;-)

>
> The only change I suggest is to always print the name of any conflicting
> pages, since it's hard to find the conflicting Relation pages -- you
> still have lots of pages in the Relation namespace, but most are
> #REDIRECTs.

Yes, certainly (Denny is in charge of the script).

>
> After running this you still need to find every link to Relation: or
> Attribute: in your wiki and change to Property:.  I'm not sure how to
> script this.

Actually I even wonder whether you would want to retain the redirects for=20
Relation pages, given that the links to Attribute:... are all broken anyway=
=2E=20
It might be better to completely close down the Relation namespace. I will=
=20
discuss this with Denny.

>
>
> BTW, both SMW_unifyProperties.php and SMW_refreshData.php report the
> same set of warnings (below) about
>    $wgAutoloadClasses[SMWResultPrinter]         =3D $smwgIP .
> '/includes/SMW_QueryPrinter.php';
>    ...
> should these array keys be in single quotes?

Oops, my bad. Fixed in SVN.

=2D- Markus

>
> $ ../../../php/php.exe SMW_refreshData.php -v
>
> Notice: Use of undefined constant SMWResultPrinter - assumed
> 'SMWResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 81
>
> Notice: Use of undefined constant SMWTableResultPrinter - assumed
> 'SMWTableResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 82
>
> Notice: Use of undefined constant SMWListResultPrinter - assumed
> 'SMWListResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 83
>
> Notice: Use of undefined constant SMWTimelineResultPrinter - assumed
> 'SMWTimelineResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 84
>
> Notice: Use of undefined constant SMWEmbeddedResultPrinter - assumed
> 'SMWEmbeddedResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 85
>
> Notice: Use of undefined constant SMWTemplateResultPrinter - assumed
> 'SMWTemplateResultPrinter' in
> C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_G=
lo
>balFunctions.php on line 86



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

[SMW-devel] SMW 0.7 seems to be work in postgresql

[Fernando C. - I. <ca...@fi...>]

Hello.
We have patched a SMW 07 sources to work with Postgresql. This version 
also has patched to work in spanish.
Seems to be work for us, but I think that someone else can be test it.

How can we publish the patched version? (an the patch for 
SMW_InlineQueries...)

Thanks.
Fernando Carpani.
Sebastian Beceiro.

Re: [SMW-devel] SMW_unifyProperties.php and Re: [Semediawiki-user] A note on using SMW SVN

[cnit <cn...@un...>]

> After running this you still need to find every link to Relation: or
> Attribute: in your wiki and change to Property:.  I'm not sure how to
> script this.
Perhaps to dump an XML file, replacing links and import it back?
Dmitriy

Re: [SMW-devel] [Semediawiki-user] Another SVN-update

[<zeh...@mo...>]

Quoting S Page <ski...@ea...>:

> Add another consequence:
> 
> 4) MediaWiki 1.10 or higher is now required.
> 
> When I updated to latest SMW code in SVN while running MediaWiki 1.9.2,
> * errors because OutputPage.php doesn't have addHeadItem()

I got that error also still with MediaWiki: 1.10alpha (r20078), 
an update to MediaWiki: 1.12alpha (r26302) solved the problem.

Cheers,
Gu

[SMW-devel] SMW_unifyProperties.php and Re: [Semediawiki-user] A note on using SMW SVN

[S P. <in...@sk...>]

Markus Krötzsch wrote:

> * (maintenance script) SMW_refreshData.php 

There's another maintenance script, SMW_unifyProperties.php.  It move 
all pages in the Relation namespace to new pages in the Property 
namespace.  (The Attribute namespace becomes the Property namespace in 
SMW 1.0, so attribute pages become property pages automatically.)  When 
I ran SMW_unifyProperties.php:

   Checking if properties need to be unified
   Unification is required. 9 relation pages need to be moved.
   1 conflicts have been detected.
   Please unify these conflicts manually.
   Moving 8 pages now.
   Unify properties script done.

After this all my Relation pages were #REDIRECTs to Property pages, 
except for the one conflict, a Relation:Climate page that conflicts with 
my former Attribute:Climate page.

The script works and seems useful, so I documented it in 
http://ontoworld.org/wiki/Upgrading_from_SMW_0.7_to_SMW_1.0

The only change I suggest is to always print the name of any conflicting 
pages, since it's hard to find the conflicting Relation pages -- you 
still have lots of pages in the Relation namespace, but most are #REDIRECTs.

After running this you still need to find every link to Relation: or 
Attribute: in your wiki and change to Property:.  I'm not sure how to 
script this.


BTW, both SMW_unifyProperties.php and SMW_refreshData.php report the 
same set of warnings (below) about
   $wgAutoloadClasses[SMWResultPrinter]         = $smwgIP . 
'/includes/SMW_QueryPrinter.php';
   ...
should these array keys be in single quotes?

$ ../../../php/php.exe SMW_refreshData.php -v

Notice: Use of undefined constant SMWResultPrinter - assumed 
'SMWResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 81

Notice: Use of undefined constant SMWTableResultPrinter - assumed 
'SMWTableResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 82

Notice: Use of undefined constant SMWListResultPrinter - assumed 
'SMWListResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 83

Notice: Use of undefined constant SMWTimelineResultPrinter - assumed 
'SMWTimelineResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 84

Notice: Use of undefined constant SMWEmbeddedResultPrinter - assumed 
'SMWEmbeddedResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 85

Notice: Use of undefined constant SMWTemplateResultPrinter - assumed 
'SMWTemplateResultPrinter' in 
C:\xampplite\htdocs\mediawiki\extensions\SemanticMediaWiki\includes\SMW_GlobalFunctions.php 
on line 86

[SMW-devel] Another SVN-update

[Markus <ma...@ai...>]

Hi all,

as promissed, I have now changed SMW's JavaScript loading to work on demand=
=20
(thanks to Ittay Dror for providing the initial SMW0.7 patch on which this=
=20
method is built). This has some consequences for those of you who use SMW=20
from SVN:

(1) Page loading should be faster in many cases.
(2) You have to touch your LocalSettings.php after update. (This means, you=
=20
need to open and resave it, or run "touch" on a Linux server, to update its=
=20
last change date). This will clear MediaWiki's parsercache -- otherwise som=
e=20
cached pages might lack necessary JavaScripts.
(3) It's not well tested yet. Use with care.

Also, the tooltips currently reuse some code from Timeline, which makes the=
m=20
heavier than they should be. We will take care of this next.

Developers who make *direct* use of SMW-scripts (without using SMW-function=
s=20
that do it) now need to call the function smwfRequireHeadItem to make sure=
=20
the script is loaded. Available built-ins are=20
smwfRequireHeadItem(SMW_SCRIPT_TIMELINE),=20
smwfRequireHeadItem(SMW_SCRIPT_TOOLTIP), and=20
smwfRequireHeadItem(SMW_SCRIPT_SORTTABLE). Developers can also use SMW's=20
on-demand loading for their own scripts (and even for other header elements=
=20
like the META-tags discussed recently). See the source code for=20
smwfRequireHeadItem for details.

Cheers,

Markus

=2D-=20
Markus Kr=C3=B6tzsch
Institut AIFB, Univers=C3=A4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

[SMW-devel] Embedding SMW-data into XHTML-headers (Was: [Mediawiki-l] Dublin Core metadata?)

[Markus <ma...@ai...>]

On Freitag, 28. September 2007, Sean O'Connor wrote:
> Dan, thanks, I'll look at semantic mediawiki.
>
> > SMW has means of using Dublin Core and any other vocabulary, but it
> > does not embedd the annotations into the XHTML-header (as I know some
> > webpages do with DC).
>
> Markus, that would be a problem for me.  Part of the reason I need DC
> on my site is to interact with applications such as Zotero [1],
> allowing researchers to grab bibliography/citation information from
> the page.

It would be possible to make certain properties available in the XHTML head=
er,=20
but this is clearly not useful for all data SMW collects (this would make t=
he=20
header really large). So the best solution would probably be an extension t=
o=20
SMW which "knows" the DC properties and treats them in a special way. We ar=
e=20
planning to put together the infrastructure for adding predefined propertie=
s=20
in extensions more easily, but an ad hoc solution can be done with the=20
current version already. There might be some performance issues though, sin=
ce=20
Meta-tags added to wiki-output are not cached. Should be OK for smaller=20
wikis.

But anyway, here is a sketch of the solution. Install SMW1.0alpha(SVN) and =
add=20
the following to your LocalSettings.php:


$wgHooks['BeforePageDisplay'][] =3D 'metaTest';

function metaTest(&$out) {
	if ($out->isArticle()) {
		$page =3D Title::newFromText($out->getPageTitle());
		$dccreator =3D Title::newFromText('dccreator', SMW_NS_PROPERTY);
		$res =3D smwfGetStore()->getPropertyValues($page, $dccreator);
		foreach ($res as $creator) {
			$out->addMeta('DC.Creator', $creator->getShortHTMLText());
		}
	}
	return true;
}


Then, whenever you use a property called "dccreator" in your wiki (the name=
 is=20
hardcoded above, feel free to change it), a metatag will appear in the=20
according XHTML page. A test page for instance could=20
contain "[[Dccreator::John Doe]]" (no page for Property:Dccreator is needed=
=20
if you want dccreators to be given by pages in the wiki).=20

Of course, this method is just a 15min hack -- there might be encoding issu=
es=20
in some cases; the datatype of the property does not matter (use what you=20
think is cool); there are no proper URIs, only plain text strings here (of=
=20
course this could be changed, if your tool can handle URIs); and there is=20
this performance thingy of querying the store on every page view (if there=
=20
would be more properties, a general condition for checking through all of=20
those would be handy, e.g. one could do this only when the page is in a=20
certain category). I am also unsure whether the above method of finding the=
=20
current page title is really right, but it worked for me so far.


=2D- Markus

>
> [1]http://www.zotero.org



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

Re: [SMW-devel] Semantic link for citations

[Markus <ma...@ai...>]

As a general answer: we currently do not consider a feature for adding=20
citations to semantic facts, and I think it is not yet clear how this shoul=
d=20
best be done in general. If some concrete plans for doing this emerge here,=
=20
we could consider this after SMW1.0 (we will have to start gathering new=20
feature requests after the release anyway :-).=20

As S said, n-ary relations are currently the only (still experimental) way =
of=20
binding multiple facts together in one annotation, but I don't think that=20
n-aries were really tailored for *this* use! So I would not really recommen=
d=20
this unless you have some properties where the citation really is almost a=
=20
fixed part of the annotation.

See further comments below (also relating to Jeff's initial request).

On Samstag, 29. September 2007, Dan Bolser wrote:

<snip>

>
> I would really like to see some 'proper' support for citations in MW
> (or SMW). I think the biggest current problem is that a citation is
> not an 'independent object', but is always found in ad-hoc
> associations with facts. I think the fact source (the citation) should
> exist in the wiki as a separate page (object) with several internal
> relations, such as 'is paper' and 'in journal' etc. etc.

Good idea. See my homepage korrekt.org for how this can be used to make a=20
citation database with dynamic publication listings. An example of such a=20
list is http://korrekt.org/index.php/Publications_by_type. I will probably=
=20
write some tutorial about this when I am done. It turns out that publicatio=
ns=20
can have quite a number of properties, and formatting them with MW template=
s=20
is some work too. I will also implement some bibtex conversion for MW when =
I=20
find the time.

>
> In this way a fact is linked to a citation object, possibly along with
> a comment describing the nature of the link.

I am somewhat uncertain what a "fact" in general would be. I guess a lot of=
=20
the citations in current wikis do not refer to single semantic facts, but t=
o=20
more complex or informal statements. I also would like to know *why* one=20
would want to annotate semantic facts with sources. Do you want to take thi=
s=20
into account for searching or browsing? I mean, having data available is=20
always nice, but which current functions of SMW would actually benefit from=
=20
citations that are attached to semantic facts (note that SMW queries have n=
o=20
explanation feature: they cannot currently tell you, which facts an answer=
=20
was based on)?

Cheers,

Markus

>
> I am still learning about SMW stuff, so please slap me if the above looks
> dumb.
>
> I am planning to integrate some 'deep' citation support here;
>
> http://introductome.org/
>
>
> But for the time being its just an advert for wish-list functionality.
>
> Dan.
>
> > Hope this helps,
> > --
> > =3DS Page
> >
> >
> > -----------------------------------------------------------------------=
=2D-
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Sem...@li...
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

Re: [SMW-devel] Newly deprecated functions in SMW_Language.php are broken

[Louis G. <lge...@gm...>]

Thanks for the info. I mainly just wanted to make sure it was not some
sort of oversight, since deprecating (as opposed to removing them)
made no sense to me.

I am using 1.0pre-alpha for a project that is nowhere near ready to
deploy, and thus having a totally stable build right now is not a
major issue (and I am more than happy to throw away my base dataset
and reload it with each build). Hence I would much rather be tracking
1.0 right now than deploying on 0.7 in 6 months and upgrading. I have
been working on getting the various extensions I use all playing nice
with each other.

The fact that I hit this right as you committed was dumb luck. I wish
I could claim I was diligently watching your commit logs thinking
through changes as you did them, but you actually literally broke code
I had written less than 24 hours before, so my first assumption was I
had just done something wrong. I was sort of embarrassed I had missed
the deprecated warnings, until I ran "svn blame" and saw they had been
added after I wrote the code ;-)

Anyway, thanks for the insight into how deprecation versus removal
happen in the project. And thanks for the excellent project. I will
almost certainly be posting some more questions in near future.

Louis

Re: [SMW-devel] Newly deprecated functions in SMW_Language.php are broken

[Markus <ma...@ai...>]

=46irstly: run the maintenance script "SMW_refreshData.php -p -v" after thi=
s=20
recent update. Otherwise some properties will report "unknown types". This =
is=20
not a bug but a necessary conversion of the remaining old types to the new=
=20
type system (I still need to do implementations, but the DB entries for typ=
es=20
now should be mostly stable).

On Samstag, 29. September 2007, Louis Gerbarg wrote:
> In the last day or so several functions in SMW_Language.php were
> deprecated as part of some changes to the type system. The deprecated
> functions were also broken at that time. I wrote a patch to fix them,=20
> but noticed that changing the internal keys to in the type system
> effectively changes their interface in such a way that it requires a
> bit of extra code to actually get them to behave in the way they did
> before. I think that either the functions should be entirely removed,
> or they will need to be fixed.

Indeed. I did not expect anybody to notice so quickly (are many people alre=
ady=20
using SMW1.0alpha-SVN?). I will write a few words below to explain the=20
change. Especially, the functions were not only deprecated but actually=20
replaced by working alternatives (see comments on each function below). The=
=20
functions should just be removed now, but I am about to do a few similar=20
cleanups soon, so things are not quite proper yet.=20

The main changes I did are:
* The messageIDs for types have completely vanished from the system. We hav=
e=20
used internal IDs before already, so the message IDs were a useless=20
complication inherited from earlier versions.
* It is now possible to register new datatypes very very easily, and all th=
ese=20
new datatypes will work properly with all relevant functions in SMW (I writ=
e=20
a separate email with the details).
* Datatypes now can have aliases. This addresses a current "bug" that the=20
English datatypes are not recognised in non-English labels. I also extended=
=20
the language files to include the English aliases by default (another mail=
=20
with infos for translators will come when I finished this bug completely;=20
special properties also still need similar aliases).

>
> getDatatypeLabel:
> This takes labels that have constant values, but all the old constants
> (i.e. "smw_wikipage") were changed, so anyone calling it is likely to
> error out anyway.
>
> findDatatypeMsgID:
> This used to return the old labels, now it would return the new
> labels, which will have the same compatibility issues as
> getDatatypeLabel.

As I said, there are no more message IDs. The mapping between type IDs and=
=20
user labels is now achieved with two new functions:

SMWDataValuefactory::findTypeID("user label for type");

SMWDataValuefactory::findTypeLabel("_internalID");

>
> getAllDatatypeLabels
> While it would be possible to make hashes to convert between the old
> name and the new names to fix the last two, this basically hands back
> an internal array which now has totally different keys. So long as the
> array is totally static at run time you could just build one and hand
> it back, but it seems likely to have serious issues if it ever gets
> modified at runtime.

Yes. We now have the method

SMWDataValuefactory::getKnownTypeLabels();

which behave pretty similar, but also uses the new ids as keys.

>
> That also totally ignores the fact that removing a type ("smw_bool")
> also breaks any legacy users of these interfaces.=20

I don't know of any. Since SMW1.0 really changes a lot (that's why it's not=
=20
0.8), I really urge all people who program on top of SMW to contact us or t=
he=20
devel list for support. If we know that someone uses functions from some=20
particular file, we can also send around notifications on major changes.

> Given the small=20
> number of users, and the challenges in keeping the interface behaving
> correctly, I personally think it should just be entirely removed.

Agreed. Converting any existing implementation to the new values should be=
=20
easy anyway.

>
> Of course, I just wrote a patch to migrate SF onto these functions
> instead of direct array access... sorry Yaron, I will have to work up
> something new for you ;-)

As I said, I really hope that the new functions are almost equivalent, the=
=20
only change being that they now use the short internal IDs consistently, an=
d=20
that extension datatypes will also show up. But don't hesitate to ask if yo=
u=20
encounter problems.=20

Markus

>
> Louis
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

Re: [SMW-devel] Semantic link for citations

[Dan B. <dan...@gm...>]

On 29/09/2007, S Page <in...@sk...> wrote:
> I'm responding, but I don't have the answers.
>
> Jeff Thompson wrote:
> > What are the plans in Semantic Mediawiki to capture citations?  I ask b=
ecause,
> > for a "cited by" property, the subject is not the article, but a partic=
ular
> > assertion made within the article.
> >
> > For example the article for Germany:
> > http://ontoworld.org/wiki/Germany
> > says it has
> > [[area::357,050km=B2]]
> >
> > This might be followed by a citation link to the World Factbook, but th=
e link is not
> > connected in a semantic way.
>
> N-ary relations in 1.0 pre-alpha let you create [[Property:Area]] with
> multiple types [[has type::Area; URI]] , and then you can say
>    has area  [[area::357,050km=B2 ;
> https://www.cia.gov/library/publications/the-world-factbook/geos/gm.html]=
]
>
> The second value is optional.
>
> I made Property:Area_test Try it,
> http://ontoworld.org/wiki/Sandbox#Area_with_citation
>
> This currently exports in RDF as:,
>
>   <property:Area_test-23m-26sup2-3B-3B>
>    <smw:nary1
> rdf:datatype=3D"http://www.w3.org/2001/XMLSchema#float">357050000000</smw=
:nary1>
>    <smw:nary2
> rdf:datatype=3D"">https://www.cia.gov/library/publications/the-world-fact=
book/geos/gm.html</smw:nary2>
>   </property:Area_test-23m-26sup2-3B-3B>
>
> The area type has units m=B2, I think that's why they become an encoded
> part of the property name (#m&sup2;;).  Within this property, you just
> have to know that the second value is a citation.
>
> If you don't like the display format then you could use a template that
> provides alternate text after '|'.
>
> There might be a way to tie into Mediawiki's reference support
> (http://en.wikipedia.org/wiki/Wikipedia:Footnotes) so that the citation
>   appears in a footnote.  I think <ref> information is structural rather
> than semantic.

Can you expand on this a bit? I am not sure what you mean.


> > You might add a property inside the assertion like this:
> >
> > [[area::357,050km=B2 [[cited by::https://www.cia.gov/library/publicatio=
ns/the-world-factbook/geos/gm.html]] ]]
>
> That won't work.  Nor can you have the citation in the alternate display
> text after '|'.  1.0 seems to better support wiki formatting in the
> displayed text, but not a nested property.
>
> > If not this, then are there plans to formally capture citations?
>
> I don't know.  People on this mailing list have discussed the
> limitations of n-ary relations as a collection of types rather than
> nested properties.

I would really like to see some 'proper' support for citations in MW
(or SMW). I think the biggest current problem is that a citation is
not an 'independent object', but is always found in ad-hoc
associations with facts. I think the fact source (the citation) should
exist in the wiki as a separate page (object) with several internal
relations, such as 'is paper' and 'in journal' etc. etc.

In this way a fact is linked to a citation object, possibly along with
a comment describing the nature of the link.

I am still learning about SMW stuff, so please slap me if the above looks d=
umb.

I am planning to integrate some 'deep' citation support here;

http://introductome.org/


But for the time being its just an advert for wish-list functionality.

Dan.








>
> Hope this helps,
> --
> =3DS Page
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>


--=20
hello

Re: [SMW-devel] Semantic link for citations

[S P. <in...@sk...>]

I'm responding, but I don't have the answers.

Jeff Thompson wrote:
> What are the plans in Semantic Mediawiki to capture citations?  I ask because,
> for a "cited by" property, the subject is not the article, but a particular
> assertion made within the article.
> 
> For example the article for Germany:
> http://ontoworld.org/wiki/Germany
> says it has
> [[area::357,050km²]]
> 
> This might be followed by a citation link to the World Factbook, but the link is not
> connected in a semantic way.

N-ary relations in 1.0 pre-alpha let you create [[Property:Area]] with
multiple types [[has type::Area; URI]] , and then you can say
   has area  [[area::357,050km² ;
https://www.cia.gov/library/publications/the-world-factbook/geos/gm.html]]

The second value is optional.

I made Property:Area_test Try it,
http://ontoworld.org/wiki/Sandbox#Area_with_citation

This currently exports in RDF as:,

  <property:Area_test-23m-26sup2-3B-3B>
   <smw:nary1
rdf:datatype="http://www.w3.org/2001/XMLSchema#float">357050000000</smw:nary1>
   <smw:nary2
rdf:datatype="">https://www.cia.gov/library/publications/the-world-factbook/geos/gm.html</smw:nary2>
  </property:Area_test-23m-26sup2-3B-3B>

The area type has units m², I think that's why they become an encoded
part of the property name (#m&sup2;;).  Within this property, you just
have to know that the second value is a citation.

If you don't like the display format then you could use a template that
provides alternate text after '|'.

There might be a way to tie into Mediawiki's reference support
(http://en.wikipedia.org/wiki/Wikipedia:Footnotes) so that the citation
  appears in a footnote.  I think <ref> information is structural rather
than semantic.


> You might add a property inside the assertion like this:
> 
> [[area::357,050km² [[cited by::https://www.cia.gov/library/publications/the-world-factbook/geos/gm.html]] ]]

That won't work.  Nor can you have the citation in the alternate display
text after '|'.  1.0 seems to better support wiki formatting in the
displayed text, but not a nested property.

> If not this, then are there plans to formally capture citations?

I don't know.  People on this mailing list have discussed the
limitations of n-ary relations as a collection of types rather than
nested properties.

Hope this helps,
--
=S Page

[SMW-devel] Newly deprecated functions in SMW_Language.php are broken

[Louis G. <lge...@gm...>]

In the last day or so several functions in SMW_Language.php were
deprecated as part of some changes to the type system. The deprecated
functions were also broken at that time. I wrote a patch to fix them,
but noticed that changing the internal keys to in the type system
effectively changes their interface in such a way that it requires a
bit of extra code to actually get them to behave in the way they did
before. I think that either the functions should be entirely removed,
or they will need to be fixed.

getDatatypeLabel:
This takes labels that have constant values, but all the old constants
(i.e. "smw_wikipage") were changed, so anyone calling it is likely to
error out anyway.

findDatatypeMsgID:
This used to return the old labels, now it would return the new
labels, which will have the same compatibility issues as
getDatatypeLabel.

getAllDatatypeLabels
While it would be possible to make hashes to convert between the old
name and the new names to fix the last two, this basically hands back
an internal array which now has totally different keys. So long as the
array is totally static at run time you could just build one and hand
it back, but it seems likely to have serious issues if it ever gets
modified at runtime.

That also totally ignores the fact that removing a type ("smw_bool")
also breaks any legacy users of these interfaces. Given the small
number of users, and the challenges in keeping the interface behaving
correctly, I personally think it should just be entirely removed.

Of course, I just wrote a patch to migrate SF onto these functions
instead of direct array access... sorry Yaron, I will have to work up
something new for you ;-)

Louis

[SMW-devel] Semantic link for citations

[Jeff T. <je...@th...>]

What are the plans in Semantic Mediawiki to capture citations?  I ask because,
for a "cited by" property, the subject is not the article, but a particular
assertion made within the article.

For example the article for Germany:
http://ontoworld.org/wiki/Germany
says it has
[[area::357,050km²]]

This might be followed by a citation link to the World Factbook, but the link is not
connected in a semantic way.  You might add a property inside the assertion like this:

[[area::357,050km² [[cited by::https://www.cia.gov/library/publications/the-world-factbook/geos/gm.html]] ]]

If not this, then are there plans to formally capture citations?

[SMW-devel] using SMW as a tool for vocabulary management and SA-WSDL - would it work?

[Martin L. <mar...@it...>]

Hi,

=20

Estonian Department of State Information Systems is looking for a tool =
where the developers of state registries (e.g. information systems like =
Land Cadastre, Population Register etc) can collaboratively create and =
manage a vocabulary (lightweight ontology incl subclassing, owl =
domain-range). The vocabulary will be used to add semantic annotations =
into WSDL =96 using W3C=92s recommendation SA-WSDL. More information =
about semantic interoperability architecture and requirements @ =
http://www.riso.ee/en/files/EstonianGov_Semantic_Description-Instructions=
_v1.1c.pdf =
<http://www.riso.ee/en/files/EstonianGov_Semantic_Description-Instruction=
s_v1.1c.pdf> .

=20

I hope to get answers from the SMW development community:

=20

1. is SMW reasonable for such purpose? Can one use SMW=92s categories =
and other constructs to =93simulate=94 rdfs/owl=92s classes, =
domains-ranges, subclasses?

=20

2. does SMW provide URL=92s for wiki=92s categories which can be =
dereferenced according to (i) SA-WSDL and (ii) Best Practice Recipes for =
Publishing RDF Vocabularies =96 Recipe #5 =
(http://www.w3.org/TR/swbp-vocab-pub/#recipe5)? For example URL =
http://www.gov.ee/ontologies/landsurvey/cadastral_unit links to category =
=93Cadastral unit=94. Depending on HTTP GET accept parameter =96 whether =
it is application/rdf+xml or text /html =96 the answer should be HTML or =
RDF.

=20

If some features =96 to fulfill the abovementioned requirements =96 are =
missing from current version of SMW, we are able to support the =
development of SMW (eg programming).

=20

=20

Thanks,

Martin

Re: [SMW-devel] Any additional tables needed for semediawiki?

[Markus <ma...@ai...>]

On Donnerstag, 27. September 2007, Yaron Koren wrote:
> Semantic MediaWiki creates and uses three additional database tables
> besides the ones used by MediaWiki: one for attributes, one for relations
> and one for "special properties" (i.e., types).

In fact, the upcoming version has more than three SWM tables, improving=20
support for different datatypes. But I guess the number does not really=20
matter. The key point is that SMW does not change the tables of MediaWiki,=
=20
and thus does not affect the wiki's normal operation.

=2D- Markus

>
> On 9/27/07, Wang, Alex (NIH/CIT) [E] <wa...@ma...> wrote:
> >  I am trying to evaluation semediawiki as a base for a professional wik=
i.
> > One question I have is about the data model. I have read the installati=
on
> > instructions and some other documentation about semantic mediawiki
> > extension. It seems, there are no additional tables created for semantic
> > mediawiki. It uses the same tables as mediawiki.
> >
> >
> >
> > Am I right?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Alex
> >
> >
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------------=
=2D-
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Sem...@li...
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

Re: [SMW-devel] Any additional tables needed for semediawiki?

[Yaron K. <ya...@gm...>]

Semantic MediaWiki creates and uses three additional database tables besides
the ones used by MediaWiki: one for attributes, one for relations and one
for "special properties" (i.e., types).

-Yaron

On 9/27/07, Wang, Alex (NIH/CIT) [E] <wa...@ma...> wrote:
>
>  I am trying to evaluation semediawiki as a base for a professional wiki.
> One question I have is about the data model. I have read the installation
> instructions and some other documentation about semantic mediawiki
> extension. It seems, there are no additional tables created for semantic
> mediawiki. It uses the same tables as mediawiki.
>
>
>
> Am I right?
>
>
>
> Thanks,
>
>
>
> Alex
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>

[SMW-devel] Any additional tables needed for semediawiki?

[Wang, A. (NIH/C. [E] <wa...@ma...>]

I am trying to evaluation semediawiki as a base for a professional wiki.
One question I have is about the data model. I have read the
installation instructions and some other documentation about semantic
mediawiki extension. It seems, there are no additional tables created
for semantic mediawiki. It uses the same tables as mediawiki.

=20

Am I right?

=20

Thanks,

=20

Alex

=20

=20

=20

Re: [SMW-devel] News on SMW 1.0

[cnit <cn...@un...>]

> Finally, we were rightly asked to provide a parser function for <ask>
> (something like {{#ask|...}}). This would yield full template compatibility.
> The new "::" syntax is one step towards this, the better datavalue formatting
> is another one. What is really missing is the conversion of HTML-query
> outputs to wiki text. We still consider whether this is realistic for SMW
> 1.0 ... I will discuss this on the devel list.

Mediawiki is strange thing - why in the world they are using different
type of outputs for parser functions and for parser tags?
Unfortunately, these things are preserved for better compatibility,
and won't be fixed.

Though I don't know why can't MW crew introduce a feature to parser's
setHook method:
instead of
  function setHook( $tag, $callback )

  function setHook( $tag, $callback, $expandTemplates = false )

so, the extension like SMW can register with something like:
  $wgParser->setHook( "ask", cbfn, true )
  
no incompatibility will be introduced in such case (because third
parameter is optional).

About conversion of HTML-query output into the wiki text, is it really
necessary? I've thought that ask results are lists of the pagenames
(Titles) and values of propeties? Then, these are unlikely have to
contain HTML tags or wiki-tags, they should be plain UTF8 texts with
no special purpose characters, am I wrong?

Or, that's because of fansy HTML tables formatting ("table" attribute
of ask query)? Then, maybe it's better to limit functionality of
{{#ask|...}} to plain lists and template output? Or, just a one base
output class and extend with two different methods - one for <ask>,
another for {{#ask}}..
Dmitriy

Re: [SMW-devel] Small patch

[Markus <ma...@ai...>]

On Montag, 24. September 2007, Louis Gerbarg wrote:
> I have been tinkering with Semantic MediaWiki a bit on and off. Today when
> I tried to setup a new install from SVN on a Mediawiki 1.10 installation I
> experienced a failure going to the Special:SMWAdmin page. Apparently
> sysopRequired has been disabled (it appears to have been deprecated for
> quite some time).
> Attached is a patch that fixed the problem for me. I am not an expert on
> the internals of MediaWiki, but I believe this is the correct credential,
> in my limited testing it prevented the page from working when I was not
> logged in on an admin account, and worked when I was logged in as an admi=
n.

Thanks, I have applied the patch in SVN (although I used=20
permissionRequired('delete') instead of permissionRequired('siteadmin'),=20
since the former is what we require).

In general, making SMWAdmin available to anyone who can delete seems to be=
=20
wrong, but the really restrictive rights like siteadmin require extra=20
configuration to be available to anyone at all. Maybe we will at least add =
an=20
option to restrict SMWAdmin to those.

Markus

>
> Louis



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

Re: [SMW-devel] Developers' update on SMW

[Yaron K. <ya...@gm...>]

Hi Markus,

Thanks a lot for this update, and for the corresponding one on the SMW-user
list. This clears up a lot. There's a lot more going in to the new version
than I had thought. The performance improvements sound great - I never
thought SMW 0.7 was/is that slow, but it's been an issue for some people.

My only concern about the new version is that I think the handling of n-ary
relations, as I understand it, could be improved; but it'll still obviously
be better than the current situation.

-Yaron


On 9/21/07, Markus Kr=F6tzsch <ma...@ai...> wrote:
>
> Hi developers,
>
> as Yaron pointed out to me, there are quite some people now developing
> code on
> top of SMW whom we ought to give much more details on the changes in
> SMW1.0.
> Yes, we will increase our support for developers.
>
> I will sum up the main internal changes (skip what you find
> uninteresting):
>
> =3D=3D Storage =3D=3D
>
> SMW now has a completely new storage access implementation. No more
> SQL-queries, just calls to some specific storage class. In this way, SMW
> is
> becoming completely detached from the DB layout (and in fact from the
> whole
> DB technology). For instance, there were some complaints that SMW's table=
s
> use too much disk space due to extensive indexing. In order to change the
> DB
> layout and index structures, one now would merely have to rewrite a singl=
e
> (albeit long) file, while the rest of the code remains untouched. This
> would
> also allow RDF-stores to be connected to SMW in a clean way.
>
> The store has many methods for accessing data, and more will be added. Th=
e
> file includes/store/SMW_Store.php gives an overview.
>
> =3D=3D Properties =3D=3D
>
> There no longer is a distinction between attributes and relations.
> Basically,
> all code now looks like the former attribute-code, i.e. relations now are
> a
> special type of attribute (i.e. property). Usually this simplifies things
> a
> lot since half of all code is obsolete.
>
> =3D=3D Datavalues =3D=3D
>
> Values of properties in SMW are now internally represented by their own
> proper
> containers. There has been SMWDataValue before, but it was now completely
> rewritten and extended in functionality. The old typehandler code will
> disappear, and implementing new datatypes will become easier (basically,
> you
> just make a subclass of SMWDataValue).
>
> Since relations now are a kind of property, there is also a datatype
> for "relations", called Type:Page. It also has a special datavalue
> implementation, called SMWWikiPageValue, which is used instead of the
> Title
> objects that were representing values of relations in SMW0.7. Often this
> is
> faster, and in any case it unifies the treatment.
>
> Datavalues now also may hold a "caption", i.e. an alternative label to be
> used
> for printouts. In annotations, this would be as follows:
>
> [[property::value|caption]]
>
> Few will need to know this, but you may see parameters called "caption" i=
n
> the
> code.
>
> =3D=3D=3D How do I check the type of some datavalue? =3D=3D=3D
>
> You can check the type of a datavalue by the method getTypeID(). All
> built-in
> types have fixed, internal IDs that you can check for. For instance,
> '_wpg'
> is for Wikipage and '_str' is for String. The wikipage type has some
> nonstandard methods that emulate methods of former Title objects. If you
> still need a title object, you can get one via
> SMWWikiPageValue::getTitle().
> This should make code updates easier.
>
> User-defined types use the DBKey of their Type-Pages as ID, so you would
> get
> something like 'Geographic_length' there. But normally you do not want to
> check for this within the code anyway.
>
> In case of "composite types" (nary properties), you just get '__nry' as a
> type
> id (the double "_" indicates that this is an internal type that has no
> translation into user speak). To find out the exact structure of such an
> nary
> datavalue container, you can call getType(). It returns to you a special
> kind
> of value: the value used for the property "has type". So the value
> describes
> an SMW datatype as specified by a user.
>
> The file SMW_DV_Types.php contains the implementation of this datavalue.
> The
> *type* of this container is '__typ', and the *value* of this container
> describes a (unary or nary) type. Bascically, it holds just an array of
> one
> or more types. You can use the method getTypeLabels() to get an array of
> the
> user labels of all those types, or you can use getTypeValues() to get an
> array of typevalues representing those types. You can check whether a
> typevalue represents a unary type by using the method isUnary(). The ID o=
f
> a
> unary typevalue can be obtained with the method getXSDValue(), but for
> nary
> values this is a string that represents all IDs, separated by ';'. Thus,
> for
> nary typevalues, you should first call getTypeValues() and then
> getXSDValue
> for each entry. There is currently no way of directly getting an array of
> IDs
> from a typevalue. If this is handy to you, I will add it.
>
> =3D=3D=3D How can I create new datavalue objects? =3D=3D=3D
>
> Creating new datavalues is really easy. There is a static class
> SMWDataValueFactory that has all kinds of convenient methods for making
> new
> datatypes:
>
> If you have the ID (e.g. '_wpg' or '_int') of a type, you can use the
> method
> newTypeIDValue(), optionally with initial value and caption.
>
> If you have a typevalue object for a type, you can use the method
> newTypeObjectValue(), optionally with initial value and caption.
>
> If you want a value for a certain property, you can use
> newPropertyObjectValue
> (if you have the property's Title object) or newPropertyValue (if you jus=
t
>
> have the name of the property). Wit newSpecialValue you can make a
> suitable
> value for a special property.
>
> The factory also does caching for faster response, and provides some
> convenience methods to check the type of some property without making an
> empty datavalue object for it.
>
>
> =3D=3D Tooltips =3D=3D
>
> We now have a universal tooltipping facility. You just insert some HTML
> anywhere and our JavaScript will make a pretty tooltip for you. There are
> two
> kinds of tooltips:
>
> * Nonessential, inline tooltips. These will not be visible if JavaScript
> is
> disabled and they will go away when the mouse is moved. Do not use these
> for
> long or important texts. To create such a tooltip, write something like:
>
> <span class=3D"smwttinline">Anchor Text<span
> class=3D"smwttcontent">Some<br/>Tooltip</span></span>
>
> * Important, persistent tooltips. The conten of those will be visible if
> JavaScript is turned off, and they are clicked and explicitly closed. The=
y
> can hold much content, since you can scroll down if needed (but do not
> overdo
> it). To create such a tooltip, write something like:
>
> <span class=3D"smwttpersist">Anchor Text<span
> class=3D"smwttcontent">Some<br />Tooltip</span></span>
>
> Instead of textual anchors, you can also use icons provided by SMW, e.g.
> as
> follows:
>
> <span class=3D"smwttpersist"><span class=3D"smwtticon">warning.png</span>=
<span
> class=3D"smwttcontent">Some<br />Tooltip</span></span>
>
> NOTE: although these tooltips can be used everywhere, we do not provide
> support for their direct use in wikipages. You can insert these texts in
> any
> page when editing, but it is likely that in the near future the required
> JavaScript can only be requested programmatically, so that user-created
> tooltips would fail.
>
> =3D=3D Queries =3D=3D
>
> There is now a whole internal API for queries. You can issue a query as
> before
> by giving a query string, but you can also construct a query from PHP
> objects. These object-based query representations are found in the file
> SMW_Description.php and SMW_Query.php.
>
> The static methods of SMW_QueryPorcessor.php can convert a query string
> into
> an object-based query, and it would be possible to work on those queries
> with
> your own code (e.g. to add conditions or to optimise something). The
> Ask-Special shows how to go from query string to printout now.
>
> Simlilarly, results are not directly printed from SQL but have an
> intermediate
> result representation that is accessed by query printers. All query
> printers
> were rewritten to use this structure. Usually things get easier, but
> printing
> queries still requires three nested loops (that's the results structure
> ...)
> and so code tends to get messy.
>
> Yet we think that the new internal interfaces are more convenient for
> issuing
> queries from your own code, for instance since you do not need
> language-specific strings as for the earlier query strings. Of course its
> also more efficient if you do not need a query string to be parsed.
>
>
> =3D=3D What else? =3D=3D
>
> I think this addresses most relevant changes. Feel free to ask questions
> on
> how to port your code to SMW1.0. Yaron also asked me why the devel list i=
s
>
> not used for making design decisions. The reason is that SMW was develope=
d
> within the Halo project in the past months, and design decisions had to b=
e
> made during real world meetings. Also, the core developers at the moment
> are
> only Denny and I, so we just talk during lunch breaks instead of starting
> email threads. We will try to improve ;-)
>
>
> Cheers,
>
> Markus
>
> --
> Markus Kr=F6tzsch
> Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
> phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
> ma...@ai...        www  http://korrekt.org
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>

[SMW-devel] Developers' update on SMW

[Markus <ma...@ai...>]

Hi developers,

as Yaron pointed out to me, there are quite some people now developing code=
 on=20
top of SMW whom we ought to give much more details on the changes in SMW1.0=
=2E=20
Yes, we will increase our support for developers.

I will sum up the main internal changes (skip what you find uninteresting):

=3D=3D Storage =3D=3D

SMW now has a completely new storage access implementation. No more=20
SQL-queries, just calls to some specific storage class. In this way, SMW is=
=20
becoming completely detached from the DB layout (and in fact from the whole=
=20
DB technology). For instance, there were some complaints that SMW's tables=
=20
use too much disk space due to extensive indexing. In order to change the D=
B=20
layout and index structures, one now would merely have to rewrite a single=
=20
(albeit long) file, while the rest of the code remains untouched. This woul=
d=20
also allow RDF-stores to be connected to SMW in a clean way.

The store has many methods for accessing data, and more will be added. The=
=20
file includes/store/SMW_Store.php gives an overview.

=3D=3D Properties =3D=3D

There no longer is a distinction between attributes and relations. Basicall=
y,=20
all code now looks like the former attribute-code, i.e. relations now are a=
=20
special type of attribute (i.e. property). Usually this simplifies things a=
=20
lot since half of all code is obsolete.

=3D=3D Datavalues =3D=3D

Values of properties in SMW are now internally represented by their own pro=
per=20
containers. There has been SMWDataValue before, but it was now completely=20
rewritten and extended in functionality. The old typehandler code will=20
disappear, and implementing new datatypes will become easier (basically, yo=
u=20
just make a subclass of SMWDataValue).

Since relations now are a kind of property, there is also a datatype=20
for "relations", called Type:Page. It also has a special datavalue=20
implementation, called SMWWikiPageValue, which is used instead of the Title=
=20
objects that were representing values of relations in SMW0.7. Often this is=
=20
faster, and in any case it unifies the treatment.

Datavalues now also may hold a "caption", i.e. an alternative label to be u=
sed=20
for printouts. In annotations, this would be as follows:

[[property::value|caption]]

=46ew will need to know this, but you may see parameters called "caption" i=
n the=20
code.

=3D=3D=3D How do I check the type of some datavalue? =3D=3D=3D

You can check the type of a datavalue by the method getTypeID(). All built-=
in=20
types have fixed, internal IDs that you can check for. For instance, '_wpg'=
=20
is for Wikipage and '_str' is for String. The wikipage type has some=20
nonstandard methods that emulate methods of former Title objects. If you=20
still need a title object, you can get one via SMWWikiPageValue::getTitle()=
=2E=20
This should make code updates easier.

User-defined types use the DBKey of their Type-Pages as ID, so you would ge=
t=20
something like 'Geographic_length' there. But normally you do not want to=20
check for this within the code anyway.

In case of "composite types" (nary properties), you just get '__nry' as a t=
ype=20
id (the double "_" indicates that this is an internal type that has no=20
translation into user speak). To find out the exact structure of such an na=
ry=20
datavalue container, you can call getType(). It returns to you a special ki=
nd=20
of value: the value used for the property "has type". So the value describe=
s=20
an SMW datatype as specified by a user.=20

The file SMW_DV_Types.php contains the implementation of this datavalue. Th=
e=20
*type* of this container is '__typ', and the *value* of this container=20
describes a (unary or nary) type. Bascically, it holds just an array of one=
=20
or more types. You can use the method getTypeLabels() to get an array of th=
e=20
user labels of all those types, or you can use getTypeValues() to get an=20
array of typevalues representing those types. You can check whether a=20
typevalue represents a unary type by using the method isUnary(). The ID of =
a=20
unary typevalue can be obtained with the method getXSDValue(), but for nary=
=20
values this is a string that represents all IDs, separated by ';'. Thus, fo=
r=20
nary typevalues, you should first call getTypeValues() and then getXSDValue=
=20
for each entry. There is currently no way of directly getting an array of I=
Ds=20
from a typevalue. If this is handy to you, I will add it.

=3D=3D=3D How can I create new datavalue objects? =3D=3D=3D

Creating new datavalues is really easy. There is a static class=20
SMWDataValueFactory that has all kinds of convenient methods for making new=
=20
datatypes:

If you have the ID (e.g. '_wpg' or '_int') of a type, you can use the metho=
d=20
newTypeIDValue(), optionally with initial value and caption.

If you have a typevalue object for a type, you can use the method=20
newTypeObjectValue(), optionally with initial value and caption.

If you want a value for a certain property, you can use newPropertyObjectVa=
lue=20
(if you have the property's Title object) or newPropertyValue (if you just=
=20
have the name of the property). Wit newSpecialValue you can make a suitable=
=20
value for a special property.

The factory also does caching for faster response, and provides some=20
convenience methods to check the type of some property without making an=20
empty datavalue object for it.


=3D=3D Tooltips =3D=3D

We now have a universal tooltipping facility. You just insert some HTML=20
anywhere and our JavaScript will make a pretty tooltip for you. There are t=
wo=20
kinds of tooltips:

* Nonessential, inline tooltips. These will not be visible if JavaScript is=
=20
disabled and they will go away when the mouse is moved. Do not use these fo=
r=20
long or important texts. To create such a tooltip, write something like:

<span class=3D"smwttinline">Anchor Text<span=20
class=3D"smwttcontent">Some<br/>Tooltip</span></span>

* Important, persistent tooltips. The conten of those will be visible if=20
JavaScript is turned off, and they are clicked and explicitly closed. They=
=20
can hold much content, since you can scroll down if needed (but do not over=
do=20
it). To create such a tooltip, write something like:

<span class=3D"smwttpersist">Anchor Text<span=20
class=3D"smwttcontent">Some<br />Tooltip</span></span>

Instead of textual anchors, you can also use icons provided by SMW, e.g. as=
=20
follows:

<span class=3D"smwttpersist"><span class=3D"smwtticon">warning.png</span><s=
pan=20
class=3D"smwttcontent">Some<br />Tooltip</span></span>

NOTE: although these tooltips can be used everywhere, we do not provide=20
support for their direct use in wikipages. You can insert these texts in an=
y=20
page when editing, but it is likely that in the near future the required=20
JavaScript can only be requested programmatically, so that user-created=20
tooltips would fail.

=3D=3D Queries =3D=3D

There is now a whole internal API for queries. You can issue a query as bef=
ore=20
by giving a query string, but you can also construct a query from PHP=20
objects. These object-based query representations are found in the file=20
SMW_Description.php and SMW_Query.php.=20

The static methods of SMW_QueryPorcessor.php can convert a query string int=
o=20
an object-based query, and it would be possible to work on those queries wi=
th=20
your own code (e.g. to add conditions or to optimise something). The=20
Ask-Special shows how to go from query string to printout now.

Simlilarly, results are not directly printed from SQL but have an intermedi=
ate=20
result representation that is accessed by query printers. All query printer=
s=20
were rewritten to use this structure. Usually things get easier, but printi=
ng=20
queries still requires three nested loops (that's the results structure ...=
)=20
and so code tends to get messy.

Yet we think that the new internal interfaces are more convenient for issui=
ng=20
queries from your own code, for instance since you do not need=20
language-specific strings as for the earlier query strings. Of course its=20
also more efficient if you do not need a query string to be parsed.


=3D=3D What else? =3D=3D

I think this addresses most relevant changes. Feel free to ask questions on=
=20
how to port your code to SMW1.0. Yaron also asked me why the devel list is=
=20
not used for making design decisions. The reason is that SMW was developed=
=20
within the Halo project in the past months, and design decisions had to be=
=20
made during real world meetings. Also, the core developers at the moment ar=
e=20
only Denny and I, so we just talk during lunch breaks instead of starting=20
email threads. We will try to improve ;-)


Cheers,

Markus

=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org

[SMW-devel] News on SMW 1.0

[Markus <ma...@ai...>]

Hi all,

Denny and I have been hard to communicate with recently, mostly due to our=
=20
high workloads. Please bear with us. I will now take some time to shed some=
=20
light on the upcoming SMW 1.0 release.

[In all feature description below, the keyword "will" is used to describe=20
features that are not implemented in SVN yet, but that are planned for 1.0.]

=3D=3D Main visible changes =3D=3D

(1) "Relations" and "Attributes" are joined and become "Properties"

* The "default type" of a (untyped or nonexisting) property is "Page", i.e.=
=20
such properties just behave like relations in SMW 0.7
* You can continue to use "::" and ":=3D", but there is no difference. We=20
suggest "::", since it can be used in template parameters where "=3D" is=20
problematic.
* The former syntactic hint that "::" is a link while ":=3D" is not has thu=
s=20
been given up, but this distinction got heavily diluted recently by more=20
elaborate datatypes anyway. Also, many users had problems of distinguishing=
=20
the two things.
* The Special pages are simplified -- basically half of them is gone.

NOTE: the word "property" is the nicest thing we could come up with for=20
English (its a technical term anyway, but better ideas could be taken into=
=20
account). It also resembles common Semantic Web speak. Other languages do n=
ot=20
have this bias and can seek better terms if they like. For example, I think=
=20
that German SMW will use "Attribut" since "Eigenschaft" ("Property" in=20
German) sounds queerer.

(2) Novel, more versatile tooltips

* Tooltips now can be inserted much easier into many places, and SMW makes =
use=20
of this possibility a lot.
* Error messages in the factbox now become tooltips, and there will be the=
=20
option of displaying these error messages even inline in little tooltips=20
(useful if you disable the Factbox).
* Various hints are shown in tooltips. For instance, queries now use toolti=
ps=20
for showing problems (e.g. if you typed some query that SMW did not=20
understand properly, SMW will give a small warning instead of just showing=
=20
unexpected results).

(3) Significant speed-up

* SMW 0.7 was slow -- not because of heavy querying but because of the shee=
r=20
amounts of code being loaded all the time (shame on us).
* 1.0 loads significantly faster, yielding a noticable speedup in normal=20
operation
* Loading of JavaScripts will be controlled more carefully to prevent too m=
uch=20
single loading requests to the server per page view.
* Queries, when restricted to the query power of SMW0.7, should be faster.

(4) More powerful querying, more semantic expressivity

* Queries now are really *parsed* and *preprocessed* before being executed.=
=20
This enables much cleaner handling and new features.
* Queries support disjunctions everywhere.
* Queries support value inequality ("search for all pages with a population=
=20
that is unequal to '50000'" -- useless example, but you get the point). Not=
e=20
that this has nothing to do with negation.
* Subproperty statements are supported, and are taken into account for=20
querying.
* Redirects work like equality even on subqueries.
* Queries report all errors and problems that occurred from parsing over=20
preprocessing to execution. For example, if you use a query that is bigger=
=20
than the configuration of the site allows, you will see a warning (this was=
 a=20
source for much confusion before).

(5) Improved display of datatypes

* Data values used for semantic annotation now have more control over their=
=20
display. In particular, HTML and Wiki versions of a datavalue are separated=
=2E=20
This will enable things like linked URLs to work properly (you will not=20
see "[http://... ]" in query results anymore).

(6) N-ary datatypes

* There has been discussion about this already, and I will write an extra m=
ail=20
on this. For now just note that (a) naries do not support all features and=
=20
datatypes yet, (b) naries are distinct from "subpages" (groups of annotatio=
ns=20
that are, well, grouped), (c) the availability of naries *now* does not=20
preclude the addition of grouped annotations *later*, and both things have=
=20
different uses.

(7) Ontology import revived

* Well, some people wanted it, here it is. We still do not really recommend=
=20
it, since it cannot create meaningful page contents but just empty pages wi=
th=20
annotations.
* But it is smart enough not to duplicate existing annotations.

(8) Nl language translation (thanks to Siebrand Mazeland)

(9) A completely new set of bugs (many old bugs gone, many new introduced).


=46inally, we were rightly asked to provide a parser function for <ask>=20
(something like {{#ask|...}}). This would yield full template compatibility=
=2E=20
The new "::" syntax is one step towards this, the better datavalue formatti=
ng=20
is another one. What is really missing is the conversion of HTML-query=20
outputs to wiki text. We still consider whether this is realistic for SMW=20
1.0 ... I will discuss this on the devel list.

=3D=3D Main invisible changes =3D=3D

* Basically, almost everything was rewritten more or less completely, or wi=
ll=20
be rewritten before the release. I will send details to the devel list soon=
=2E=20
Anyway, many changes should be convenient to developers of SMW-extensions,=
=20
but we are aware that more documentation is needed.


=3D=3D When? When is the release? When can I safely use SVN? =3D=3D

We *want* to release SMW 1.0 around the first week of October. At least som=
e=20
release candidate should be out by that time. Main open issues are:

* Upgrade path: the merger of Relations and Attributes requires you to merg=
e=20
two namespaces. Basically, the Attribute namespace is automatically renamed=
=20
to "Property" but the pages from "Relation:" must be moved over. You can do=
=20
this manually or (with some care) on the database, but we would like to=20
provide you with some automated way of doing this. This is the main=20
show-stopper for SMW1.0.
* Bugs: there are some medium-sized issues that we definitely want to fix.
* Documentation: the docu is not complete yet.
* Internal changes: there are still a number of "old" files that ought to b=
e=20
replaced by new implementations in SMW1.0 (though most of them already have=
).=20
This is a prerequisite for some bugfixes/improvements.

So should you upgrade to SVN? Well, you could, but note that there is no wa=
y=20
back to SMW 0.7 (especially the DB-layout changed). At least ontoworld and=
=20
various other wikis use the current alpha version and are working reasonabl=
y=20
well. You can use MediaWiki 1.10. To upgrade, you need to first go to=20
Special:SMWAdmin as usual, and press the button. If you have a large wiki,=
=20
this may take some time, and you should better use our new maintenance scri=
pt=20
SMW_setup.php. Next you should run the maintenance script=20
SMW_refreshData.php, maybe twice (on large wikis, run it only for propertie=
s=20
first, see docu in the script file). Finally you can bother how to get your=
=20
Relation-pages ("Relation:" still exists) into "Property:". This is not=20
critical for the wiki to work, but you get a lot of red links in the Factbo=
x.

Also, if your wiki is large, you may want to restrict the new query=20
expressivity. See the parameters in SMW_Settings.php (copy your own setting=
s=20
to LocalSettings.php). Especially equality (redirects) and subproperty=20
queries in combination tend to puzzle MySQL, possibly leading to long query=
=20
times. We look out for further optimisation before releasing.


=3D=3D What is it with this Halo-Project? =3D=3D

As some of you may know, we are employing and extending SMW within a projec=
t=20
called "Halo", together with the company ontoprise. Our work on many=20
SMW-features have been funded by this project, and these parts are just=20
included into SMW1.0.=20

Other features are more application-specific (Halo is targetting=20
knowledge-engineering in certain application domains in the natural=20
sciences), or tailored towards smaller wikis or specific tasks (e.g. the ta=
sk=20
of adding inline annotations to otherwise finished pages). These parts of=20
Halo will be released as an extension package to SMW1.0, that can be=20
installed, enabled, and disabled at your liking. I assume that there will=20
also be a public demonstration wiki at some time. It is not clear at the=20
moment how and if these Halo extensions are going to be maintained beyond=20
SMW1.0, but they are all in the open source so that alignment with future S=
MW=20
releases should be possible. The targetted release date for the Halo=20
extensions is around Oct 15.


OK, you are now up-to-date concerning general SMW ongoings. I will answer=20
further specific questions in separate emails, especially on the devel list.

Cheers,

Markus



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
ma...@ai...        www  http://korrekt.org