Re: [Wikidata-l] When the source says the information provided is dubious

[Friedrich Röhrs]

Hi,

These sort of things could also be modeled with another statement and
opposite properties.

If there is one Statement with the claim Chopin -- creator_of --> Nr. 17
with multiple source (Kobylańska and others), another statement with the
claim Chopin -- not_creator_of --> Nr. 17 with a source (Chomińsk) can be
added.

I dont know if this sort of properties is wanted though.


On Tue, May 6, 2014 at 2:06 PM, David Cuenca  wrote:

> On Tue, May 6, 2014 at 1:37 PM, Thomas Douillard <
> thomas.douill...@gmail.com> wrote:
>
>> We could create a new qualifier like ''contradicted by'' or ''disputed
>> by''. The sourcs are a problem though as we can source only the totality of
>> a claim, not only a qualifier of this claim, so we would have to source all
>> the sources for the claim and it's disputation sources in the source
>> without order..
>>
>
> I have mixed feelings about that... it is good because it doesn't require
> any development, it isn't that good because it mixes claim and source...
> And having a "reference rank" to indicate if the source is "supporting",
> "against" or "unsure" about the claim seems too much work for the number of
> times that such feature would be needed
>
> Thanks,
> Micru
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] 'Person' or 'human', upper ontologies and migrating 4 million claims

[Friedrich Röhrs]

Hi,

shouldn't the start be to decide what the requirements towards the
classification scheme are? Without knowing what the goal for the
classification scheme should be it seems to me to be very hard (or
arbitrary) to look at different upper ontologies and say "hey this one will
fit our project". Also there might be some technical limitations that need
to be taken into account (while overviewing the discussion i saw something
about no binary properties).

Good day,
Friedrich


On Thu, Sep 5, 2013 at 6:06 AM, emw  wrote:

> Hi Wikidatans,
>
> The conclusion of the 'Primary sorting property' RFC is that property P107
> -- main type (GND) -- will be deleted [1, 2, 3].  The most popular option
> for replacing P107 is to use properties P31 and P279 ('instance of' and
> 'subclass of'), which are based on rdf:type and rdfs:subclassOf [4, 5].
> Unlike P107, which restricts the world into seven high-level classes,
> 'instance of' and 'subclass of' give users a flexible way to define an
> item's type.  They also enable hierarchical classification, and are in line
> with Semantic Web conventions.
>
> While general agreement exists on that much, there's active discussion in
> the new 'Migrating away from GND main type' RFC [6] about precisely how we
> want to capture P107 information with 'instance of' and 'subclass of'.
> P107 is Wikidata's most popular property by a significant margin -- it's
> currently used in 4,237,061 claims -- so it's important that we get this
> right.
>
> Many people on this list are knowledgeable about ontology and
> classification but not part of the on-wiki commentariat that tends to
> populate Wikidata RFCs.  To those people: please give your input in this
> migration RFC at
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type.
> It has some really interesting questions, like:
>
> A) How should we classify items like 'Ronald Reagan', 'Rabindranath
> Tagore' and 'Coco Chanel'?  That is, how should we classify items that have
> a GND main type of "person"?  A main critique of P107 is that it includes
> in 'person' things like gods, literary characters, spirits, and individual
> and collective pseudonyms.  It's clear we want greater precision than
> P107's "person", but it's unclear whether it'd be best to map those claims
> to instance of 'person', 'human', 'human person', or something else.
> Discussion on this is in
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#Person
> .
>
> B) How should we classify the GND main types themselves, or the classes
> they get mapped to?  This is essentially a question about upper ontologies
> [7] for Wikidata.  There are widely-used third-party upper ontologies like
> SUMO, UMBEL and BFO [8, 9, 10].  It's worth discussing which of these -- if
> any -- is best to adopt for Wikidata's high-level classification.  Although
> it probably warrants a separate RFC, some initial discussion of that is in
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#High_classification
> .
>
> C) How can we visualize the type hierarchies we're creating with P31 and
> P279?  See
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#Visualization_of_subclass_of_.28P279.29_relationship
> .
>
> The previous 'Primary sorting property' RFC was easier than this new RFC
> will be -- deciding something is a bad idea is easier than actually
> replacing it with something better.
>
> So, please join the discussion at
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type
> !
>
> Thanks,
> Eric
>
> https://www.wikidata.org/wiki/User:Emw
>
>
> 1)
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Primary_sorting_property
>
> 2) http://lists.wikimedia.org/pipermail/wikidata-l/2013-June/002451.html
>
> 3) https://www.wikidata.org/wiki/Property:P107
>
> 4) http://www.w3.org/TR/rdf-schema/#ch_type
>
> 5) http://www.w3.org/TR/rdf-schema/#ch_subclassof
>
> 6)
> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type
>
> 7) https://en.wikipedia.org/wiki/Upper_ontology
>
> 8) https://en.wikipedia.org/wiki/Suggested_Upper_Merged_Ontology
>
> 9) https://en.wikipedia.org/wiki/UMBEL
>
> 10) https://en.wikipedia.org/wiki/Basic_Formal_Ontology
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Content card prototype

[Friedrich Röhrs]

You can just open the webconsole in firefox or chrome and enter:
mw.loader.load('//
www.wikidata.org/w/index.php?title=User:Tpt/interproject.js&action=raw&ctype=text/javascript'
);
after any wikipedia page has loaded. It will show the button + card (when
hovered)


On Mon, Jun 3, 2013 at 5:35 AM, Chris Maloney  wrote:

> I'd think you could use GreaseMonkey or (on Chrome) TamperMonkey.
>
>
> On Sun, Jun 2, 2013 at 11:27 PM, Tom Morris  wrote:
>
>> Is there a way to test this without creating an account on Wikipedia?
>>
>> Tom
>>
>>
>> On Sun, Jun 2, 2013 at 11:55 AM, David Cuenca  wrote:
>>
>>> Based on all feedback gathered during the RfC about a possible
>>> inter-project links interface [1], User:Tpt has created a content card
>>> prototype (image: [2])
>>>
>>> To activate it, follow these steps:
>>>
>>>1. Go to your common.js file. For a user named "Test" in English
>>>Wikipedia, it would be:
>>>https://en.wikipedia.org/wiki/User:Test/common.js
>>>2. Modify it and paste this line: mw.loader.load('//
>>>
>>> www.wikidata.org/w/index.php?title=User:Tpt/interproject.js&action=raw&ctype=text/javascript'
>>>);
>>>3. Save and go to any Wikipedia page
>>>4. You should see an icon next to the article title, if you don't,
>>>refresh your browser cache. *Instructions*: Internet Explorer: hold
>>>down the Ctrl key and click the Refresh or Reload button. Firefox: hold
>>>down the Shift key while clicking Reload (or press Ctrl-Shift-R). Google
>>>Chrome and Safari users can just click the Reload button.
>>>
>>> What it does:
>>>
>>>- It displays an icon next to the article title
>>>- When you hover your mouse over the icon it shows a *content card*.
>>>- The content card displays information from Wikidata: label, image,
>>>link to Commons gallery, and link to edit Wikidata.
>>>
>>> What it is supposed to do in the future when Wikidata supports sister
>>> projects:
>>>
>>>- It will display contents or links to sister projects
>>>
>>> Please leave your feedback on the Request for comments, thanks!
>>>
>>>
>>> http://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_interface#Comments
>>>
>>> Cheers,
>>> Micru
>>>
>>>
>>> [1]
>>> http://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_interface
>>> [2] http://commons.wikimedia.org/wiki/File:Content-card-prototype.png
>>>
>>> ___
>>> Wikidata-l mailing list
>>> Wikidata-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>>
>>>
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] first steps of Wikidata in the Hungarian Wikipedia

[Friedrich Röhrs]

Hi,

congratulations on the great work the development team and the community made.

Cheers,
Friedrich

On Mon, Jan 14, 2013 at 9:34 PM, Lydia Pintscher
 wrote:
> Heya folks :)
>
> Today is the day. We've deployed Wikidata on the Hungarian Wikipedia
> \o/ I wrote a blog post with all the details at
> http://blog.wikimedia.de/2013/01/14/first-steps-of-wikidata-in-the-hungarian-wikipedia/
> Thank you to everyone who has helped make this happen and especially
> the Hungarian Wikipedia community for agreeing to be the first.
>
>
> Cheers
> Lydia
>
> PS: The first important edit was already made as well:
> https://hu.wikipedia.org/w/index.php?title=Triatlon&diff=12906358&oldid=12683097
>
> --
> Lydia Pintscher - http://about.me/lydia.pintscher
> Community Communications for Wikidata
>
> Wikimedia Deutschland e.V.
> Obentrautstr. 72
> 10963 Berlin
> www.wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
> Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Hi,

On Fri, Dec 21, 2012 at 6:14 PM, Denny Vrandečić
 wrote:
>
>
> Friedrich, the term "query answering" simply means the ability to answer 
> queries against the database in Phase 3, e.g. the list of cities located in 
> Ghana with a population over 25,000 ordered by population.
>
> A query system that deals well with intervals -- I would need a pointer for 
> that. For now I was always assuming to use a single value internally to 
> answer such queries. If the values is 90+-20 then the query >100? would not 
> contain that result. Sucks, but I don't know of any better system.
>

So taking the current data model and our eiffel tower example:
We have the entity "Eiffel Tower".
We want to represent "The Eiffel Tower is 324 meters high", so we
would create the statement
(
Assumptions:
wikipedia pages as ids,
I understood the wikidata object notation correctly,
Number(upperlimit lowerlimit unit) is the object notation for numbers.
I omitted the quantity field because i think its redundant at least in
this example and the confidence could be added as an additional
PropertySnak(?))
)
Statement('
http://en.wikipedia.org/wiki/Eiffel_Tower
PropertyValueSnak(' http://en.wikipedia.org/wiki/Height Number(324 324
http://en.wikipedia.org/wiki/Metre) ')
{reference and rank omitted}
')

(Note: I though I read somewhere it was decided that all statements on
wikidata should at least have one reference, but in the object
notation definition the {references} seems to imply this is a optional
argument. Also the visual has a 0..* relation, did i miss something?)

Assuming a System of tables by unit and multiples i.e. (meter is m0)
is used the table could look like this

Table m0:

propertyid | property | max | min | other information
1234 | Height | 324 | 324 | ... (or 323 | 325 )

an index could be put over min and max and property and the query for
all buildings higher then 300 meters could start with:

SELECT propertyid FROM m0 WHERE property = Height AND min > 300 OR max > 300;

This would allow a query for things with a "Height" greater then 300
and it would even include things defined as 290+-20, since the max
value would be over 300. The much harder thing imho is the "located in
Ghana" part of the query, but I think there are such things as spatial
queries for the big databases ( f.e.
http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html ).

This would also work for queries on Dates with tables that have
mindate, maxdate. ( appropo dates here is a short but interesting
discussion on how they might be saved in databases if arbitrary dates
are needed here: http://stackoverflow.com/a/2487792 )

Representation of "temporal knowledge" (?) seems to be a huge research
topic anyway (f.e.
http://www.math.unipd.it/~kvenable/RT/corso2009/Allen.pdf or
http://www.cs.ox.ac.uk/boris.motik/pubs/nm03fuzzy.pdf, ...); where the
problems about time intervals vs. time points, uncertainty and
"vagueness" and their representation is discussed.

hope this helps,

Friedrich

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Hi,

Does for me too now. Maybe i played around with the autouncertainty
checkbox before trying 324 (probably had some 4 digit value before).
Although the Problem remains, the height of the Eifeltower is not 324 +-1
meter. It is given as 324meters without any further information. So it
should either be +-0Meters, or +-unkownMeters, no? I think for most items
on Wikipedia the upperuncertainty or loweruncertainty is not known, or at
least no source gives it. So in most use cases it is an unknown value. To
make it easy for editors it should be marked as not available from the
start.

(Staying with the eiffel tower as an example i don't see what additional
information the 0.68 confidence supplies.)



On Fri, Dec 21, 2012 at 3:44 PM, Daniel Kinzler  wrote:

> On 20.12.2012 20:31, Friedrich Röhrs wrote:
> > Hi,
> >
> > tried to enter the height of the eiffel tower. 324 meters. It suggested
> 324m
> > +-100m.
>
> That's strange. When I enter 324m, it correctly suggests 324m+/-1 for me.
>
> -- daniel
>
> --
> Daniel Kinzler, Softwarearchitekt
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Hi,

tried to enter the height of the eiffel tower. 324 meters. It suggested
324m +-100m. So i clicked on details and emptied the the +/- fields,
because i do not know the upper or lower bounds. Would that have been the
correct way to do it? Or should i set them to 0, even though i don't know
at which precision this measurement is done. There should be a n/a value
set as standard for the precision imho because for most items the precision
is not known.

Friedrich


On Thu, Dec 20, 2012 at 5:10 PM, Denny Vrandečić <
denny.vrande...@wikimedia.de> wrote:

> I am still trying to catch up with the whole discussion and to distill the
> results, both here and on the wiki.
>
> In the meanwhile, I have tried to create a prototype of how a complex
> model can still be entered in a simple fashion. A simple demo can be found
> here:
>
> 
>
> The prototype is not i18n.
>
> The user has to enter only the value, in a hopefully intuitive way (try it
> out), and the full interpretation is displayed here (that, alas, is not
> intuitive, admittedly).
>
> Cheers,
> Denny
>
>
>
>
>
> 2012/12/20 
>
> **
>>
>> (Proposal 3, modified)
>> * value (xsd:double or xsd:decimal)
>>
>> * unit (a wikidata item)
>>
>> * totalDigits (xsd:smallint)
>> * fractionDigits (xsd:smallint)
>> * originalUnit (a wikidata item)
>> * originalUnitPrefix (a wikidata item)
>> JMc: I rearranged the list a bit and suggested simpler naming
>>
>> JMc: Is not originalUnitPrefix directly derived from originalUnit?
>>
>> JMc: May be more efficient to store not reconstruct the original value. May 
>> even be better to store the original value somewhere else entirely, earlier 
>> in the process, eg within the context that you indicate would be worthwhile 
>> to capture, because I wouldnt expect alot of retrievals, but you anticipate 
>> usage patterns certainly better than I.
>>
>>
>> How about just:
>>
>>
>> Datatype: .number  (Proposal 4)
>>
>> -
>>   :value (xsd:double or xsd:decimal)
>>
>>   :unit (a wikidata item)
>>   :totalDigits (xsd:smallint)
>>   :fractionDigits (xsd:smallint)
>>
>>
>>   :original (a wikidata item that is a number object)
>>
>> On 20.12.2012 03:08, Gregor Hagedorn wrote:
>>
>> On 20 December 2012 02:20,   wrote:
>>
>> For me the question is how to name the precision information. Do not the
>> XSD facets "totalDigits" and "fractionDigits" work well enough? I mean
>>
>> Yes, that would be one way of modeling it. And I agree with you that,
>> although the xsd attributes originally are devised for datatypes,
>> there is nothing wrong with re-using it for quantities and
>> measurements.
>>
>> So one way of expressing a measurement with significant digits is:
>> (Proposal 1)
>> * normalizedValue
>> * totalDigits
>> * fractionDigits
>> * originalUnit
>> * normalizedUnit
>>
>> To recover the original information (e.g. that the original value was
>> in feet with a given number of significant digits) the software must
>> convert normalizedUnit to originalUnit, scale to totalDigits with
>> fractionDigits, calculate the remaining powers of ten, and use some
>> information that must be stored together with each unit whether this
>> then should be expressed using an SI unit prefix (the Exa, Tera, Giga,
>> Mega, kilo, hekto, deka, centi, etc.). Some units use them, others
>> not, and some units use only some. Hektoliter is common, hektometer
>> would be very odd. This is slightly complicated by the fact that for
>> some units prefix usage in lay topics differs from scientific use.
>>
>> If all numbers were expressed ONLY as total digits with fraction
>> digits and unit-prefix, i.e. no power-of-ten exponential, the above
>> would be sufficiently complete. However, without additional
>> information it does not allow to recover the entry:
>>
>> 100,230 * 10^3 tons
>> (value 1.0023e8, 6 total, 3 fractional digits, original unit tons,
>> normalized unit gram)
>>
>> I had therefore made (on the wiki) the proposal to express it as:
>>
>> (Proposal 2)
>> * normalizedValue
>> * significantDigits (= and I am happy with totalDigits instead)
>> * originalUnit
>> * originalUnitPrefix
>> * normalizedUnit
>>
>> However I see now that the analysis was wrong, indeed it needs
>> fractionDigits in addition to totalDigits, else a similar problem may
>> occur, i.e. the distribution of the total order of magnitude of the
>> number between non-fractional digits, fractional digits, powers of 10
>> and powers-of-10-expressed through SI units is still not unambigous.
>>
>> So the minimal representation seems to be:
>>
>> (Proposal 3)
>> * normalizedValue (xsd:double or xsd:decimal)
>> * totalDigits (xsd:smallint)
>> * fractionDigits (xsd:smallint)
>> * originalUnit (a wikidata item)
>> * originalUnitPrefix (a wikidata item)
>> * normalizedUnit (a wikidata item)
>>
>> Adding the originalUnitPrefix has the advantage that it gathers
>> knowledge from users and data creators or resources about which unit
>> pref

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

When we speak about dimensions, we talk about properties right?

So when I define the property "height of a person" as an entity, i would
supply the SI unit (m) and the SI multiple (-2, cm) that it should be saved
in (in the database).

When someone then inputs the height in meters (e.g. 1.86m) it would be
converted to the matching SI multiple before being saved (i.e. 186 (cm)).

On the database side each SI multiple would get its own table so that
indexes can easily be made. Depending on which multiple we choose in the
property the datavalue would be saved to a different table. Did i get the
idea correctly?


On Wed, Dec 19, 2012 at 4:47 PM, Gregor Hagedorn wrote:

> On 19 December 2012 15:11, Daniel Kinzler 
> wrote:
> > If they measure the same dimension, they should be saved using the same
> unit
> > (probably the SI base unit for that dimension). Saving values using
> different
> > units would make it impossible to run efficient queries against these
> values,
> > thereby defying one of the major reasons for Wikidata's existance. I
> don't see a
> > way around this.
>
> Daniel confirms (in separate mail) that Wikidata indeed intends to
> convert any derived SI units to a common formula of base units.
>
> Example: a quantity like "1013 hektopascal", the common unit for
> meterological barometric pressure (this used to be millibar), would be
> stored and re-displayed as
> 1.013 10^5 kg⋅m−1⋅s−2
>
> I see several problems with this approach:
>
> 1. Many base units are little known. "kg⋅m2⋅s−3⋅A−2" for Ohm... It
> breaks communication with humans curating data on wikidata. It will
> make it very difficult to compare data entered into wikidata for
> correctness, because the data displayed after saving will have little
> relation with the data entered. This makes Wikidata inherently
> unsuitable for an effort like Wikipedia with many authors and the
> reliance on fact checking.
>
> 2. Even for standard base units, there is often a 1:n relation. e,g,
> both gray   and sievert have the same base unit. The base unit for
> lumen
> is candela (because the steradians is not a unit, but part of the
> derived unit applicability definition)
>
> Gregor
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Hi,

Sorry for my ignorance, if this is common knowledge: What is the use case
for sorting millions of different measures from different objects?
The only use case i can think of where the sorting would be necessary is
lists like "cities in France by size" or "list of cars by fuel/per 100km".
Those list do not have millions of entries, and even there you would need
some further logic, since the size is not just one single value, there
could be multiple values for the size (or fuel consumption) with different
sources and for different times. For cars there could be entries by the
manufacturer, by some car-testing magazine, etc. I don't see how this could
be adequatly represented/sorted by a database only query.

If however this is necessary, i still don't understand why it must affect
the datavalue structure. If a index is necessary it could be done over a
serialized representation of the value. This needs to be done anyway, since
the values are saved at a specific unit (which is just a wikidata item). To
compare them on a database level they must all be saved at the same unit,
or some sort of procedure must be used to compare them (or am i missing
something again?).

Friedrich


On Wed, Dec 19, 2012 at 12:25 PM, Gregor Hagedorn wrote:

> On 19 December 2012 11:56, Friedrich Röhrs 
> wrote:
> > I don't understand why 1.6e-8 is absolutly necessary for sorting and
> > comparison. PHP allows for the definition of custom sorting functions.
> If a
> > custom datatype is defined, a custom sorting/comparision function can be
> > defined too. Or am i missing some performance points?
>
> I believe for performance reasons in many cases sorting needs to be
> performed already by the database and supported by an index. -- gregor
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

I don't understand why 1.6e-8 is absolutly necessary for sorting and
comparison. PHP allows for the definition of custom sorting functions. If a
custom datatype is defined, a custom sorting/comparision function can be
defined too. Or am i missing some performance points?


On Wed, Dec 19, 2012 at 10:30 AM, Nikola Smolenski wrote:

> On 19/12/12 08:53, Gregor Hagedorn wrote:
>
>> I agree. What I propose is that the user interface supports entering
>> and proofreading "10.6 nm" as "10.6" plus "n" (= nano) plus "meter".
>> How the value is stored in the data property, whether as 10.6 floating
>> point or as 1.6e-8 is a second issue -- the latter is probably
>> preferable. I only intend to show that scientific values are not
>>
>
> Perhaps both should be stored. 1.6e-8 is necessary for sorting and
> comparison. But 10.6 nm is how the user entered it, presumably how it was
> written in the source that the user used, how is it preferably used in the
> given field, and how other users would want to see it and edit it.
>
> As an example, human height is commonly given in centimetres, while
> building height is commonly given in metres. So, users will probably prefer
> to edit the tallest person as 282cm and the lowest building as 2.1m even
> though the absolute values are similar.
>
>
> __**_
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Denny,

could you maybe elaborate on what you mean by query answering? Do you talk
about some technical aspect of the wiki-software?


thanks,


On Tue, Dec 18, 2012 at 5:08 PM, Sven Manguard wrote:

> How about this:
>
> - Values default to a non-range value
> - You can click a checkbox that says "range" to turn the input into a
> range value instead
> - An entry can only be represented by either a non-range or a range
> number, not both
>
> This relieves our issue with query answering:
>
> Query: When was XXX invented?
>
> Non-range answer: June 1988
>
> Range answer: sometime between May 1988 and October 1989
>
>
> Does that work?
>
> Sven M
>
> On Tue, Dec 18, 2012 at 10:56 AM, Denny Vrandečić <
> denny.vrande...@wikimedia.de> wrote:
>
>> Thank you for your comments, Friedrich.
>>
>> It would be possible and very flexible, and certainly more powerful than
>> the current system. But we would loose the convenience of having one date,
>> which we need for query answering (or we could default to the lower or
>> upper bound, or the middle, but all of these are a bit arbitrary).
>>
>> The other option would be, as discussed in the answer to Marco, to use
>> one data and an uncertainty, probably an uncertainty with a unit (and
>> probably different lower and upper bounds). This would make it more
>> consistent to the ways numbers are treated.
>>
>> I start to think that the additional complexity for this solution might
>> be warranted.
>>
>>
>>
>> 2012/12/18 Friedrich Röhrs 
>>
>>> Hi,
>>>
>>> * Time:
>>>
>>> Would it make sense to use time periods instead of partial datetimes
>>> with lower precision levels? Instead of using May 1918 as birth date it
>>> would be something like "birth date in the interval 01.05.1918 -
>>> 31.05.1918". This does not necessarly need to be reflected in the UI of
>>> course, it could still allow the "leave the field you dont know blank" way.
>>> This would allow the value to be 2nd-5th century AD (01.01.100 -
>>> 31.12.400). Going with this idea all the way, datetimes at the highest
>>> precision level could be handled as periods too, just as zero length
>>> periods..
>>>
>>> Another question that popped is how to represent (or if it should be
>>> represented) times where for example the hour is known, but the day isn't.
>>> If it is known someone was killed at Noon, but not the specific day.
>>>
>>> Friedrich
>>>
>>>
>>>
>>> On Tue, Dec 18, 2012 at 3:29 PM, Denny Vrandečić <
>>> denny.vrande...@wikimedia.de> wrote:
>>>
>>>> Thanks for the input so far. Here are a few explicit questions that I
>>>> have:
>>>>
>>>> * Time: right now the data model assumes that the precision is given on
>>>> the level "decade / year / month" etc., which means you can enter a date of
>>>> birth like 1435 or May 1918. But is this sufficient? We cannot enter a
>>>> value like 2nd-5th century AD (we could enter 1st millenium AD, which would
>>>> be a loss of precision).
>>>>
>>>> * Geo: the model assumes latitude, longitude and altitude, and defines
>>>> altitude as over mean sea level (simplified). Is altitude at all useful?
>>>> Should it be removed from Geolocation and be moved instead to a property
>>>> called "height" or "altitude" which is dealt with outside of the
>>>> geolocation?
>>>>
>>>> * Units are currently planned to be defined on the property page (as it
>>>> is done in SMW). So you say that the height is measured in Meter which
>>>> corresponds to 3.28084 feet, etc. Wikidata would allow to defined linear
>>>> translations within the wiki and can thus be done by the community. This
>>>> makes everything a bit more complicated -- one could also imagine to define
>>>> all dimensions and units in PHP and then have the properties reference the
>>>> dimensions. Since there are only a few hundred units and dimensions, this
>>>> could be viable.
>>>>
>>>> (Non-linear transformations -- most notoriously temperature -- will get
>>>> its own implementation anyway)
>>>>
>>>> Opinions?
>>>>
>>>>
>>>>
>>>> 2012/12/17 Denny Vrandečić 
>>>>
>>>>> As Phase 2 is progressing, we have to decide on how to represent data

Re: [Wikidata-l] Data values

[Friedrich Röhrs]

Hi,

* Time:

Would it make sense to use time periods instead of partial datetimes with
lower precision levels? Instead of using May 1918 as birth date it would be
something like "birth date in the interval 01.05.1918 - 31.05.1918". This
does not necessarly need to be reflected in the UI of course, it could
still allow the "leave the field you dont know blank" way. This would allow
the value to be 2nd-5th century AD (01.01.100 - 31.12.400). Going with this
idea all the way, datetimes at the highest precision level could be handled
as periods too, just as zero length periods..

Another question that popped is how to represent (or if it should be
represented) times where for example the hour is known, but the day isn't.
If it is known someone was killed at Noon, but not the specific day.

Friedrich



On Tue, Dec 18, 2012 at 3:29 PM, Denny Vrandečić <
denny.vrande...@wikimedia.de> wrote:

> Thanks for the input so far. Here are a few explicit questions that I have:
>
> * Time: right now the data model assumes that the precision is given on
> the level "decade / year / month" etc., which means you can enter a date of
> birth like 1435 or May 1918. But is this sufficient? We cannot enter a
> value like 2nd-5th century AD (we could enter 1st millenium AD, which would
> be a loss of precision).
>
> * Geo: the model assumes latitude, longitude and altitude, and defines
> altitude as over mean sea level (simplified). Is altitude at all useful?
> Should it be removed from Geolocation and be moved instead to a property
> called "height" or "altitude" which is dealt with outside of the
> geolocation?
>
> * Units are currently planned to be defined on the property page (as it is
> done in SMW). So you say that the height is measured in Meter which
> corresponds to 3.28084 feet, etc. Wikidata would allow to defined linear
> translations within the wiki and can thus be done by the community. This
> makes everything a bit more complicated -- one could also imagine to define
> all dimensions and units in PHP and then have the properties reference the
> dimensions. Since there are only a few hundred units and dimensions, this
> could be viable.
>
> (Non-linear transformations -- most notoriously temperature -- will get
> its own implementation anyway)
>
> Opinions?
>
>
>
> 2012/12/17 Denny Vrandečić 
>
>> As Phase 2 is progressing, we have to decide on how to represent data
>> values.
>>
>> I have created a draft for representing numbers and units, points in
>> time, and locations, which can be found here:
>>
>> > >
>>
>> including a first suggestion on the functionality of the UI which we
>> would be aiming at eventually.
>>
>> The draft is unfortunately far from perfect, and I would very welcome
>> comments and discussion.
>>
>> We probably will implement them in the following order: geolocation, date
>> and time, numbers.
>>
>> Cheers,
>> Denny
>>
>>
>> --
>> Project director Wikidata
>> Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
>> Tel. +49-30-219 158 26-0 | http://wikimedia.de
>>
>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
>> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
>> Körperschaften I Berlin, Steuernummer 27/681/51985.
>>
>
>
>
> --
> Project director Wikidata
> Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> Tel. +49-30-219 158 26-0 | http://wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/681/51985.
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata, ISO and chembox

[Friedrich Röhrs]

Hi Luca,

a)

as far as I have understood Nadja Kutz and John McClure want the
wikidata dev team to somehow commit to using ISO topic maps for the
classification of the content of wikidata. The Dev teams position is
that how the content will finally be structured is not up to them but
to the community once the technical means to create the structure are
there.

As far as the whole arguments about using or not using ISO goes, again
as far as I have understood one position is not to use them because it
would force other wanting to adhere to the standard to also pay for it
(pay to get the documentation about how it works) and wikimedia
somehow to pay for it too, while the other position is that wikidata
should use it because its an "industry standard" and the money that
would have to be paid wasn't all that much. Furthermore the argument
is, is that if its not done, some copyright could be infringed (not
the ISO one but some other).

There are (IMHO) a multitude of topics about this whole thing, most
prominent: [Wikidata-l] [[meta:wikitopics]] updated
it's a bit hard to follow in archive because it stretches multiple months
(starting points in case you want to read up)

http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000583.html
http://lists.wikimedia.org/pipermail/wikidata-l/2012-June/000624.html
http://lists.wikimedia.org/pipermail/wikidata-l/2012-June/000638.html
[...]

b)
No one has yet identified as an attorney or copyright expert; on the
contrary most everyone has said they are not.


hope this helps,

Friedrich

On Wed, Sep 5, 2012 at 3:35 PM, Luca Martinelli
 wrote:
> Dear all,
>
> sorry but I think I didn't correctly got the point of the whole thing.
> Probably, I was overestimating my English competence, or my
> free-licensing competence, or both.
>
> So, without ANY intention of being rude, or even polemical, I would
> like to ask: "what is this discussion about, again?"
>
> If I got it right, someone expressed his/her doubts about using ISO
> standards in classifying data on Wikidata because of [this point may
> be challenged, but this is what I understood] potential ISO copyright
> issues.
>
> Now, the points are:
> a) Is my guess correct? If no, what is the point this discussion is about?
> b) Is there anyone who could answer this doubt, whatever it is?
>
> Just trying to follow this thread, nothing more. Thank you.
>
> --
> Luca "Sannita" Martinelli
> http://it.wikipedia.org/wiki/Utente:Sannita
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] reworked storyboard for linking Wikipedia articles

[Friedrich Röhrs]

I have to say i find the story board really confusing. If I click on
add language links i would assume to get some sort of form where i can
add/remove/edit language links that will be shown on the left. I have
to however choose only 1 language and suddenly many more might be
added, or none will be added. If i don't understand the underlying
workings of wikidata, i think it would seems random wether i am able
to add (i can't really do that either) a link [1] or it says no page
found [2].

Let's assume the page for Germany does not have any links yet on any
wikipedia. I would go to [3] and click [add] next to languages to add
the english version i know exsist.

I would get the modal box to enter a language [4]. I would choose
English in the first box and then start typing Germany in the second.
Then however i get [2] the no match found error. Even though i know
that is the english version of the german page.

Imho the workflow should be:

I add the first language
- if the page i choose already has a item on wikidata i get a message
saying "hey there are already other languages that are already present
are those correct?" (or similar)
- if the page i choose does not have an item on wikidata, a new item
is created and the two languages versions (in the example english and
german) are added to it.

The window will stay the same however. I think it should be [5] or similar.

I add another language link
- if the page i choose already has an item on wikidata i get a message
saying "hey there are already other languages that are already
present"
  - if that item already has a link to my language it should tell me
so "this page is currently the translation of ,
is that not correct?" (or similar)
- if the page i choose does not ahve an item on wikidata, it is added
to the item of my page as language version.

I think something like that would be easier to understand for the
user. (Or have i totally misunderstood the workflow?)

Another approach would be a wizard that explains to me i have to first
link my language version to a page on wikidata before i can add/remove
language links.

Then however it should say so in the buttons. So on the left below the
language it should have a link  and as long as
that is not done, i should not be able to add/remove/edit languages
via this bar. Once i have linked the page to a item on wikidata the
language edit feature could be activated.


Friedrich



[1] http://meta.wikimedia.org/wiki/File:Wikidata_storyboard_connect_article2.png

[2] 
http://meta.wikimedia.org/wiki/File:Wikidata_storyboard_connect_article_nomatch.png

[3] http://de.wikipedia.org/wiki/Deutschland

[4] http://meta.wikimedia.org/wiki/File:Wikidata_storyboard_connect_article1.png

[5] 
http://meta.wikimedia.org/wiki/File:Wikidata_storyboards_editlinks-addlang2.png


On Wed, Jun 20, 2012 at 4:10 PM, Gregor Hagedorn  wrote:
> I added some comments on
>
> http://meta.wikimedia.org/wiki/Talk:Wikidata/Development/Storyboard_for_linking_Wikipedia_articles_v0.2
>
> Gregor
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [[meta:wikitopics]] updated

[Friedrich Röhrs]

Hi,

"1c. You're arguing over CHF 200 -- which extraordinarily-cheaply and
fundamentally PROTECTS the MWF from copyright infringement suits? Can
the SNAK architecture provide that reassurance to the MWF community?"

imho there are some problems with this argumentation:

First i don't really know what standard you are talking about; i can't
find any "ISO Topic Map metamodel". The only publication i found was
on "Topic Maps — Data Model" which is shortened as TMDM (not TMM). Is
that the one you are referring to? There seems to be a whole group of
standards based around that specific one, for example "ISO 18048:
Topic Maps Query Language (TMQL)" and "ISO 19756: Topic Maps
Constraint Language (TMCL)" etc. (wouldn't that mean you would have to
pay for them all?)

Then you seem to be mixing the MWF as an entity and the MWF community
as a collection of individuals. Even if the MWF somehow purchased the
documentation of the standard (or standards from above) from ISO this
would mean nothing to people not part of the MWF. The "community" is
not an official part of the fundation, i.e. they are not members, so
they would have no right to the content of the standard.

The same seems to be true to any third party wanting to use the data
from wikidata. They would need to implement the standard (or even
group of standards) if they successfully wanted to use the content
offered by wikidata. To be able to do this efficiently they probably
would need to buy the standards themself. This seems to me to be
against wikimedias policy of "...the creation of content not subject
to restrictions on creation, use, and reuse.". Having to pay for a
documentation to be able to understand the structure the content is
held in seems to be a restriction the use of the data.

Furthermore i don't really understand your "copyright infringement
thread". Either we are talking about structure, which, to me it seems,
is not protected by copyright (didn't oracle just fail in court
because of that). Or do we talk about some sort of content that can be
protected by copyright? You explicitly said you where not talking
about content :"You're citing a policy about CONTENT, I see, though I
was focusing on data models and technical interface designs..."

Then again i am no laywer so don't really feel competent enough in
that field to give any real advice or have an opinion about what is
protected by copyright and what is not.

tldr: To me it seems using the ISO standard would force third parties
wanting to consume wikidata content to implement that standard too and
thus having to pay for information on how to implement it. This would
mean a (financial) restriction on the use of content which is in
conflict with wikimedias values.

Friedrich

On Wed, Jun 13, 2012 at 7:38 AM, Nadja Kutz  wrote:
> Hello John,
>
> thanks for digging this out.
>
> I see in the Brochure there is not only a postbox but they have even an
> office where one could meat the ISO:
> 1, ch. de la Voie-Creuse
>
>
> It would be interesting to hear whats Wikimedia's opinion on this.
>
>
> Nadja
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Forwarded from Wikidata-test-client

[Friedrich Röhrs]

Hi,

I am highjacking this thread because my question is also about the
location of information in the demo system, or at least what we can
edit.

is there any way to find the correspoding page on the repo
(http://wikidata-test-repo.wikimedia.de/) for a page on the client
(http://wikidata-test-client.wikimedia.de/wiki/) ?

For example data for the client page Helium
(http://wikidata-test-client.wikimedia.de/wiki/Helium) can be edited
on http://wikidata-test-repo.wikimedia.de/wiki/Data:Q2

How do i know the right Q* for any page?

The Use Case i wanted to try out was the following:

A new Wikipedia page on the client is created and the author now wants
to add interlanguage links, or at least check if they exist or if they
don't exist add them.

However I was stuck at finding the right page on the repo for the
specific client page. Is there a way to find those? And can we even
add new pages to the repo?

Thanks,
Friedrich

On Fri, Jun 8, 2012 at 5:48 PM, Daniel Kinzler
 wrote:
> On 08.06.2012 17:38, Lydia Pintscher wrote:
>> This is currently not possible and it isn't decided yet if we'll do it
>> and if so how. Currently it is just a json construct that readers
>> probably won't find very useful. It is not wiki text like you're used
>> to. If there is a specific reason why you want to see it I'd be
>> interested in hearing it so we can take it into account.
>
> In my mind, the way we store the data internally is an implementation detail 
> and
> there's no reason to expose this to the user, ever.
>
> -- daniel
>
> --
> Daniel Kinzler, Softwarearchitekt
>
> Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
> http://wikimedia.de  | Tel. (030) 219 158 260
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt
> für Körperschaften I Berlin, Steuernummer 27/681/51985.
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] mockups for linking Wikipedia articles up for feedback

[Friedrich Röhrs]

Hi,

What happens if there are conflicting information? if a user tries to
create a language link that already exists? Do they get an error? Is
the previous link overwritten? Does it fail silently?

(Or is such information not relevant for Storyboard?)

On Tue, May 8, 2012 at 3:28 PM, Brent Hecht  wrote:
> These look great! Very exciting :-)
>
> Brent Hecht
> Ph.D. Candidate in Computer Science
> CollabLab: The Collaborative Technology Laboratory
> Northwestern University
> w: http://www.brenthecht.com
> e: br...@u.northwestern.edu
>
> On May 8, 2012, at 4:46 AM, Lydia Pintscher wrote:
>
>> Heya folks :)
>>
>> We've worked on mockups for how we think linking of articles between
>> different Wikipedias should work with Wikidata. You can find the
>> mock-ups and explanations here:
>> https://meta.wikimedia.org/wiki/Wikidata/Notes/Storyboard_for_linking_Wikipedia_articles
>> It'd be great if you could have a look and give feedback either here
>> or on the discussion page on meta.
>>
>>
>> Cheers
>> Lydia
>>
>> --
>> Lydia Pintscher - http://about.me/lydia.pintscher
>> Community Communications for Wikidata
>>
>> Wikimedia Deutschland e.V.
>> Obentrautstr. 72
>> 10963 Berlin
>> www.wikimedia.de
>>
>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>>
>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
>> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
>> Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l