Semantic MediaWiki

On Tuesday 16 May 2006 17:19, Mov GP 0 wrote:
> > Markus Kr=F6tzsch wrote:
> >
> > On Tuesday 16 May 2006 10:19, Tony Bowden wrote:
> > > I haven't seen any discussion of a Currency Type. A first stage for
> > > this might be to replicate Float, but allowing the unit to
> >
> > be a prefix
> >
> > > so we can say [[cost:=3DUSD 12]] or [[cost:=3D$ 12]] or
> >
> > [[cost:=3DCHF 103]] etc.
> >
> > > This certainly won't cover every situation, particularly as
> >
> > there are
> >
> > > some currencies where the value comes first, but I'm
> >
> > throwing it out
> >
> > > as a starting point for discussion...
> > >
> > > Thoughts?
> >
> > Three thoughts:
> > (1) We need to extend the parsing of the float type to cover this.
> > Note that prefixing currencies is common only in some languages.
>
> True. But Math is international valid - and in Math the unit is on the
> trail. But it should be possible to write a Parser that can parse the Val=
ue
> neverless if the currency ist written in prefix or postfix.

Well, (uppercase;) Math does not care where things are written.=20
Mathematically, km 12/h is the same as 12 km/h. But there are of course loc=
al=20
customs one should respect.

>
> > (2) Currency can be a problematic thing to annotate, since the real
> > value of each currency changes all the time. But the wiki database is
> > updated only on saving articles, i.e. even with automatic conversion
> > between common currencies, you would soon have wrong or outdated
> > values in the database. So a real comparison between EUR 10 and USD 12
> > is not to be achieved easily.
>
> Thats the biggest problem. But there are Webservices out there which
> are providing such calculations - optionally with respect to
> historical currency exchange dates. Personally I prefer [1]. The
> biggest problem here is that such a feature would depend on the
> Webserviceprovider.
>
> [1] http://www.gama-system.com/webservices/exchangerates.asmx

Yes, that would be a useful option; and technically interesting too. But it=
 is=20
not so easy to integrate this into the architecture: instead of converting=
=20
values when they are stored, the conversion would have to take place when y=
ou=20
<ask> for data (e.g. goods sorted by *current* value). Imagine a wiki with =
a=20
couple of thousand goods (or companies) where you look for all companies=20
which are worth more than a billion USD -- you would have to send more than=
=20
1000 requests to this service at one time. And answering times would not be=
=20
reliable due to the Web in between ...

So you would need some kind of caching mechanism (maybe an in-wiki-value vs=
=2E=20
current-equivalent-value table in the database, which is continuously updat=
ed=20
by querying the webservice). Lot of new architecture to do such a thing ...

>
> > (3) Maybe currency values also behave slightly different from normal
> > decimal numbers. E.g. you would not want USD 3.4 but rather USD 3.40,
> > I guess.
>
> Thats a kind of formatting problem. I would recommend to use something
> like: [[cost:=3D"USD 12"|format=3D"*f.ff"|$&nbsp;12]]
>
> > And a workaround:
> > Currently, you can write [[cost:=3D12$|$ 12]] to get printed "$ 12"
> > where the system uses "12 $".
>
> Well, as I said already it shouldn't make any difference if the unit
> is prefix or postfix. Also we should use ISO 4217 (three letter
> curreny) only - currency symbols are not that good, because they are
> overused in different Countries.

Obviously, since there are only a handful of dedicated currency symbols. Bu=
t=20
this would be a minor problem and mapping $ to one default interpretation=20
could even be done via a message that can be edited by the wiki admin (who=
=20
can easily edit all messages via the wiki since MediaWiki 1.6).

Best regards,

Markus

>
> Ie. the letter "$" (&#24;) is used for the currencies USD, ARS, AUD,
> BBD, BZD, BOB, BND, CAD, KYD, CLP, XCD, FJD, GYD, HKD, JMD, LRD,  MXN,
> NAD, NZD, SGD, SBD, SRD, TTD, TVD, and ZWD.
>
>
> ys, MovGP0
>
> > Regards
> >
> > Markus
> >
> > > Tony
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > Using Tomcat but need to do more? Need to support web
> >
> > services, security?
> >
> > > Get stuff done quickly with pre-integrated technology to
> >
> > make your job
> >
> > > easier Download IBM WebSphere Application Server v.1.0.1 based on
> > > Apache Geronimo
> >
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D1216
> >
> > > 42 _______________________________________________
> > > Semediawiki-devel mailing list
> > > Semediawiki-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> > --
> > Markus Kr=F6tzsch
> > Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
> > mak@...        phone +49 (0)721 608 7362
> > http://www.aifb.uni-karlsruhe.de/WBS/     fax +49 (0)721 693  717
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&da=
t=121642
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

=2D-=20
Markus Kr=F6tzsch
Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
mak@...        phone +49 (0)721 608 7362
 http://www.aifb.uni-karlsruhe.de/WBS/     fax +49 (0)721 693  717

> Ie. the letter "$" () is used for the currencies USD, ARS, AUD,
> BBD, BZD, BOB, BND, CAD, KYD, CLP, XCD, FJD, GYD, HKD, JMD, LRD,  MXN,
> NAD, NZD, SGD, SBD, SRD, TTD, TVD, and ZWD.

TVD? Tuvalu has a currency of it's own?

The world really is a funny place!

:)

Cheers,
denny

>> [1] http://www.gama-system.com/webservices/exchangerates.asmx
>>     
>
> Yes, that would be a useful option; and technically interesting too. But it is 
> not so easy to integrate this into the architecture:
A modest approach would be to have a Type:Currency of Type:Float that 
remembers the units (as Float does) without doing currency exchange 
rates.  But it creates hyperlinks to currency conversion sites, much 
like geographical coordinates contains INFOLINKS to GoogleMaps and MapQuest.

--
=S

On Wed, May 17, 2006 at 01:05:16AM -0700, S Page wrote:
> >Yes, that would be a useful option; and technically interesting too. But 
> >it is not so easy to integrate this into the architecture:
> A modest approach would be to have a Type:Currency of Type:Float that 
> remembers the units (as Float does) without doing currency exchange 
> rates.  But it creates hyperlinks to currency conversion sites, much 
> like geographical coordinates contains INFOLINKS to GoogleMaps and MapQuest.

That sounds very useful. In my case I'm primarilyy interested in being
able to properly annotate the information (and potentially perform basic
calculations, such as addition, but that's another issue!) rather than
in being able to do any currency conversions.

Tony

> Tony Bowden wrote:
> 
> On Wed, May 17, 2006 at 01:05:16AM -0700, S Page wrote:
> > >Yes, that would be a useful option; and technically 
> interesting too. 
> > >But it is not so easy to integrate this into the architecture:
> > A modest approach would be to have a Type:Currency of 
> Type:Float that 
> > remembers the units (as Float does) without doing currency exchange 
> > rates.  But it creates hyperlinks to currency conversion 
> sites, much 
> > like geographical coordinates contains INFOLINKS to 
> GoogleMaps and MapQuest.
> 
> That sounds very useful. In my case I'm primarilyy interested 
> in being able to properly annotate the information (and 
> potentially perform basic calculations, such as addition, but 
> that's another issue!) rather than in being able to do any 
> currency conversions.
> 
> Tony

I'm not sure if that works in every case. Assume searching for persons
having a Fortune of more than 10 Mio. USD. In that case you need to have all
fortunes in the same unit - neverless if this currency is USD, EUR, etc., or
even a virtual Currency. 

I would say that the Database could do some caching in that case, having the
Tables containing not (only) the original value, but all USD (or any other).
In that case, the conversion (Webservice) gets called only when the article
gets saved - with the drawback that the data is not actual, except for
historical values - but therefore compareable. 

MovGP0

(Back in May Tony Bowden and MovGP0 talked about currency conversion.)

FYI, using the data-driven linear conversion code checked into CVS, I 
was able to build currency conversion.

Create a Type:Currency page with
    [[:Corresponds to:=1 USD]]

    [[:Corresponds to:= 1.1269 CDN]] ;
    [[:Corresponds to:= 2.1720 BRL]] ;
    [[:Corresponds to:= 0.523615 GBP¦pounds sterling]] ;
    [[:Corresponds to:= 7.7742 HKD]] ;
    [[:Corresponds to:= 114.21 JPY¦¥¦¥¦Japanese Yen]] (Note Yen as 
HTML entity and glyph.)
    ...

Create an Attribute:Costs page with
    [[:Has type::Type:Currency]]
    Let's only display these currency conversions:
    [[:main display unit:=USD]],
    [[:display unit:=GBP]],
    [[:display unit:=¥]].

Means you can enter in an article
    [[Costs:= 10000 Yen]], [[Costs:=500 USD]], [[Costs:=1]

and get the following in the factbox:
    Costs <http://localhost/mediawiki/index.php/Attribute:Costs> 
87.558 USD (45.847 GBP, 10,000 ¥)  , 500 USD (261.808 GBP, 57,105 ¥)  , 
and 1 USD (0.524 GBP, 114.21 ¥)

The next step would be to periodically recreate the Type:Currency page 
with the latest currency rates.  The Feds provide these as a Web 
service, so it's a Simple Matter Of Programming :-)

The time-dependent nature of currency conversion has some tricky 
problems.  If pages prominently displayed "Currency values converted as 
of  $lastmod" (normally this is shown in the page footer). that would 
hint at the accuracy of the tooltips and factbox.  But smw_attributes 
stores the value converted to the standard unit (US Dollars in my 
example).  An old page last edited in the glory days of the British 
empire that says something costs 500 GBP (pounds sterling) might store 
1900 USD in the database.  A searchtriple will convert 1900 USD at 
latest exchange rates to show 1200 GBP, which doesn't match the text of 
the page.
*  You could somehow force a refresh of every page using a currency 
value each time you update Type:Currency.
*  Maybe the attribute table should store both the value as entered and 
the value converted to the standard unit.

Another issue is supporting currency prefixes like $59.95 and £20.  It's 
easier to support this in entered Wiki text than on display which 
assumes number followed by unit is the correct float format.  This might 
be a compelling reason to implement format strings, or to build a 
dedicated currency datatype that still reads conversion factors from its 
Type page.

Feel free to enter feature requests!
--
=S

On Fri, Aug 04, 2006 at 10:56:11PM -0700, S Page wrote:
> (Back in May Tony Bowden and MovGP0 talked about currency conversion.)
> FYI, using the data-driven linear conversion code checked into CVS, I 
> was able to build currency conversion.

Nice approach.

> The time-dependent nature of currency conversion has some tricky 
> problems.  If pages prominently displayed "Currency values converted as 
> of  $lastmod" (normally this is shown in the page footer). that would 
> hint at the accuracy of the tooltips and factbox.  

I think there's two different types of conversion needed. There's the
'current value' that will vary over time in other currencies, and the
'historic price' that shouldn't. For example, if you store a list of
things purchased on your credit card, then a payment you made may
have been for CA$100, but you don't want the US$ version changing over
time - you want it fixed at whatever the exchange rate was at the time.

As I think I've noted before, my needs are generally for the second of
these, so I'm less interested in the automatic conversion than other
people. I'm happy to specify both the foreign price and local price
explicitly and don't want anything changing those later!

> Another issue is supporting currency prefixes like $59.95 and ?20.  It's 
> easier to support this in entered Wiki text than on display which 
> assumes number followed by unit is the correct float format.  

This is more of an issue for me. Having the currency string come after
the amount just looks weird. (Except of course for those currencies
where it is supposed to!)

> be a compelling reason to implement format strings, or to build a 
> dedicated currency datatype that still reads conversion factors from its 
> Type page.

I'm not sure what exactly is meant by "format strings" but it sound like
that's going to be a good idea! :)

Thanks for the work on this,

Tony