Re: [SMW-devel] News on SMW 1.0

[Markus <mak@ai...>]

On Mittwoch, 26. September 2007, cnit wrote:
> > 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 =3D 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).

I am sure they will consider a patch that implements this, if anyone submit=
s=20
it. ;-)

>
> 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?

The ask result itself, as provided by the SMW-store, is an multidimensional=
=20
array that has objects for all values that will get printed (basically the=
=20
structure is like that of ask result tables, just not as HTML but as=20
objects).

But to bring results to a page, they must be serialised in HTML or Wikitext=
=2E=20
The output of the result printers achieves that, and it is true that most o=
f=20
this output is compatible with both HTML and Wikitext (e.g. you can have HT=
ML=20
tables in both). The problems arise with links, since linked titles do not=
=20
work the same way in HTML and Wikitext. But basically this can be solved by=
=20
copying the HTML-code and replacing some innermost function calls that=20
currently make HTML-outputs instead of wikitext.

>
> 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}}..

As I said, it is not the fancy formatting but the very result list. Not a b=
ig=20
deal to change this, I think. We just need to extend the infrastructure=20
slightly, so that appropriate functions are triggered for the printers. One=
=20
then can implement those step by step. I guess chances are good that=20
{{#ask }} would replace <ask> in the long run anyway, so the added effort=20
would go away.

There are some other discussion points for {{#ask}}, which I raise in a=20
separate mail.

Markus

> Dmitriy



=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
mak@...        www  http://korrekt.org

Re: [SMW-devel] Semantic link for citations

[Markus <mak@ai...>]

On Mittwoch, 3. Oktober 2007, Jeff Thompson wrote:
> Markus Kr=F6tzsch 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?

That's no question I can answer, but we are talking to several other large=
=20
projects who plan to use 1.0. Further practical experiences with SMW are=20
important for Wikipedia. We actually do not push the issue at the moment,=20
since we have all our work-force concentrated on 1.0, and we would prefer t=
o=20
provide decent support for the upgrade.

=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
mak@...        www  http://korrekt.org

Re: [SMW-devel] coding: TypeHandlers and OldDataValue

[Markus <mak@ai...>]

On Mittwoch, 3. Oktober 2007, S Page wrote:
> I wrote code to support specifying the sort order of enumerations, much
> like Ittay Dror originally proposed:
>
>   [[allows value::Enhancement=3D-1]]
>   [[allows value::Trivial=3D0]]
>   [[allows value::Minor=3D3]], 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? =20

Yes, and before 1.0.

> If so, I=20
> have a patch for Enum that migrates it to DataValue and another patch
> that adds the ordering enhancement.

Oh, nice.

One thing though: we have discussed whether it would be better to have "all=
ows=20
value" available for every type. The current Enum then would rather be a=20
Type:String with allows value set. But all other types could allow similar=
=20
features, and we would get rid of Type:Enum completely. I guess your patche=
s=20
could still be used as a basis for all other types as well (or, for a start=
,=20
for Type:String).

Markus

>
> --
> =3DS Page



=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
mak@...        www  http://korrekt.org

[SMW-devel] coding: TypeHandlers and OldDataValue

[S Page <info@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 Thompson <jeff@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 <mak@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
mak@...        www  http://korrekt.org

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

[Fernando Carpani - INCO <carpani@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 <cnit@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

[<zehetner@mo...>]

Quoting S Page <skierpage@...>:

> 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 Page <info@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 <mak@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
mak@...        www  http://korrekt.org

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

[Markus <mak@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
mak@...        www  http://korrekt.org

Re: [SMW-devel] Semantic link for citations

[Markus <mak@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
> > Semediawiki-devel@...
> > 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
mak@...        www  http://korrekt.org

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

[Louis Gerbarg <lgerbarg@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 <mak@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
> Semediawiki-devel@...
> 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
mak@...        www  http://korrekt.org

Re: [SMW-devel] Semantic link for citations

[Dan Bolser <dan.bolser@gm...>]

On 29/09/2007, S Page <info@...> 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
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>


--=20
hello

Re: [SMW-devel] Semantic link for citations

[S Page <info@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 Gerbarg <lgerbarg@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 Thompson <jeff@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 Luts <martin.luts@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 <mak@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] <wangal@...> 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
> > Semediawiki-devel@...
> > 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
mak@...        www  http://korrekt.org

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

[Yaron Koren <yaron57@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] <wangal@...> 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
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>

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

[Wang, Alex (NIH/CIT) [E] <wangal@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 <cnit@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 <mak@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
mak@...        www  http://korrekt.org