I made some changes to the page Key:wikipedia on the wiki.
Please review:
http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603
2014-07-01 19:58 GMT-03:00 Jo winfi...@gmail.com:
I've been experimenting with Wikidata a bit. I'm not a Wikipedian, rather
a
2014-07-09 16:37 GMT+02:00 John Packer john.pack...@gmail.com:
I made some changes to the page Key:wikipedia on the wiki.
Please review:
http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603
your edit looks fine to me, besides that you removed the url
I removed the link to the key url=* because it's own wiki page advises it
shouldn't be used, so I figured there was no need to link it here.
As far as I understood, although it might make sense to tag an URL in some
cases, the meaning of this key is too generic, making it hard to be used by
2014-07-09 16:57 GMT+02:00 John Packer john.pack...@gmail.com:
I removed the link to the key url=* because it's own wiki page advises it
shouldn't be used, so I figured there was no need to link it here.
Thanks for pointing at this, I have amended this sentence to make more
sense, please
On 30 June 2014 14:30, Pieren pier...@gmail.com wrote:
the wikipedia key is still human readable
where the wikidata is just an encrypted interdatabase foreign key.
A Wikidata ID is part of a URL and can be rendered as such; for
example, Q173882 equates to https://www.wikidata.org/wiki/Q173882
On Tue, Jul 1, 2014 at 4:42 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
A Wikidata ID is part of a URL and can be rendered as such; for
example, Q173882 equates to https://www.wikidata.org/wiki/Q173882
It was said at the beginning that wikidata or wikipedia tags will
never replace OSM
2014-07-01 17:40 GMT+02:00 Pieren pier...@gmail.com:
Why should we accept one and not the others. Where
is the breaking point ?
I think the distinction to be made is whether the linked database is public
and available under an open license.
cheers,
Martin
On 01.07.2014 17:40, Pieren wrote:
It was said at the beginning that wikidata or wikipedia tags will
never replace OSM tags but now I see counter examples or duplicates of
what is already there (like on this scary proposal for the operator,
architect, brand, artist, subject, name etymology
On 1 July 2014 16:40, Pieren pier...@gmail.com wrote:
On Tue, Jul 1, 2014 at 4:42 PM, Andy Mabbett a...@pigsonthewing.org.uk
wrote:
A Wikidata ID is part of a URL and can be rendered as such; for
example, Q173882 equates to https://www.wikidata.org/wiki/Q173882
It was said at the beginning
On 01.07.2014 18:08, Tobias Knerr wrote:
OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?
Technically, we
On 01.07.2014 18:08, Tobias Knerr wrote:
OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?
Technically, we
On Wed, Jul 2, 2014 at 2:48 AM, yvecai yve...@gmail.com wrote:
I would find more logical to make links between databases with queries
rather by adding external references in one or the other. The later looks
like the poor man job (oversimplifying, I don't want to put down the great
job done
On 01.07.2014 21:04, Eugene Alvin Villar wrote:
I disagree. If the goal is to make separate databases function as one
big normalized database[1] such that there is no overlap in data, then
these inter-database references are, in fact, necessary.
I must admit, when I read 'big normalized
Am 7/1/14 20:48 , schrieb yvecai:
but no content
Maybe not directly to OSM, but definitely to the maps you can make out
of it.
http://osm.lyrk.de/wappen/
I think this is a much better solution than upldating all those image
links in OSM. And if you want to have them in OpenStreetMap you
On 01.07.2014 21:56, Andreas Goss wrote:
Am 7/1/14 20:48 , schrieb yvecai:
but no content
Maybe not directly to OSM, but definitely to the maps you can make out
of it.
http://osm.lyrk.de/wappen/
I think this is a much better solution than upldating all those image
links in OSM. And if
then search wikimedia commons for flags with the corresponding name.
Which is going to fail, because there are names that exist more than
once and always the risk of different spellings, especially in different
languages.
Also Wiki commons often does not care that much about creating
I've been experimenting with Wikidata a bit. I'm not a Wikipedian, rather a
convinced Openstreetmapper. One of the problems I had with Wiktionary and
Wikipedia is how data is duplicated over and over again. Wikidata finally
started solving that.
We should take advantage from that.
Here are some
2014-06-30 2:55 GMT+02:00 John Packer john.pack...@gmail.com:
I used wikipedia:operator instead of operator:wikipedia because the former
is used way more often
I think the semantics are different. The tag operator:wikipedia seems to me
like the wikipedia page about the operator, while
but I was aware it conflicts with the language version
The best solution would be to just use Wikidata. If editors supported
that, then they could also always show the titel of the Wikidata tag to
avoid errors.
http://wiki.openstreetmap.org/wiki/Wikidata
I think part of the confusion
On 30/06/2014 10:34, Andreas Goss wrote:
but I was aware it conflicts with the language version
The best solution would be to just use Wikidata. If editors supported
that, then they could also always show the titel of the Wikidata tag
to avoid errors.
So in this two particular cases (Bayford's head office and building, and
Buxton College with its two websites), what _actual_ tag values would
you suggest?
Cheers,
Andy
I think right now the tagging of the building is incomplete. If you want
to tag Bayford Co on the building, then the
On 30/06/2014 10:57, Andreas Goss wrote:
If the building is important I would tag the company as a seperate
node on the building and then there is no confusion with the basic tag
anymore.
I'd agree (that in the Bayford's HO case) having the company details on
a node within the building
2014-06-30 11:57 GMT+02:00 Andreas Goss andi...@t-online.de:
I think right now the tagging of the building is incomplete. If you want
to tag Bayford Co on the building, then the building should have a tag
office=company. At that moment the wiki or wikidata tag clearly refers to
them.
+1,
We're presumably suggesting wikidata=$something but what is $something?
Every Wikidata entry has an ID. You can find it in the URL and behind
the title:
OpenStreetMap: Q936
https://www.wikidata.org/wiki/Q936
So you would use wikidata=Q936
__
openstreetmap.org/user/AndiG88
On 30/06/2014 11:12, Andreas Goss wrote:
We're presumably suggesting wikidata=$something but what is
$something?
Every Wikidata entry has an ID. You can find it in the URL and behind
the title:
OpenStreetMap: Q936
https://www.wikidata.org/wiki/Q936
So you would use wikidata=Q936
That's
Bayford:
operator:wikidata=Q4874513
The ones of my previous mail should also have been operator:wikidata
Polyglot
2014-06-30 12:27 GMT+02:00 Jo winfi...@gmail.com:
The University of Derby would be:
wikidata:operator=Q3183295
Devonshire Royal Hospital
wikidata:operator=Q5267877
Does
2014-06-30 12:27 GMT+02:00 Jo winfi...@gmail.com:
The University of Derby would be:
wikidata:operator=Q3183295
Devonshire Royal Hospital
wikidata:operator=Q5267877
wouldn't operator:wikidata make more sense?
___
Tagging mailing list
Indeed, sorry about that.
2014-06-30 12:46 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com:
2014-06-30 12:27 GMT+02:00 Jo winfi...@gmail.com:
The University of Derby would be:
wikidata:operator=Q3183295
Devonshire Royal Hospital
wikidata:operator=Q5267877
wouldn't
To clarify: wikipedia:operator is exactly the same thing as
operator:wikipedia.
Historically, the key wikipedia has the same order as the key source.
It might seem strange since this conflicts with the language version, but
that's simply the result of an organic growth of the tag's definition.
On 30 June 2014 10:34, Andreas Goss andi...@t-online.de wrote:
but I was aware it conflicts with the language version
The best solution would be to just use Wikidata. If editors supported that,
then they could also always show the titel of the Wikidata tag to avoid
errors.
I'm strongly in favour of having the order as described here:
http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
The advantage is that they sort near to what they apply to,
name:etymology:wikidata is near to name, operator:wikidata is near to
operator and so on.
I'm not sure why we
I would advise to be cautious with adding wikidata tags with a bot, because
a wikipedia article could have been moved and the wikidata tag would point
to a wrong page. (i.e. the bot should also perform the standard checks even
in this case)
I believe leaving the wikipedia tag in place while
On Mon, Jun 30, 2014 at 1:36 PM, John Packer john.pack...@gmail.com wrote:
The main reason is that the wikipedia key is well established and supported
in some sites, which either point a link to it or use some image from the
page.
No, the main reason is that the wikipedia key is still human
2014-06-30 13:18 GMT+02:00 John Packer john.pack...@gmail.com:
To clarify: wikipedia:operator is exactly the same thing as
operator:wikipedia.
that's presumably how (most/all) people intended to use it, yes, but there
is no guarantee, and there is indeed room for different interpretations as
Am 6/30/14 15:30 , schrieb Pieren:
And one of the mentionned
example is providing the building operator only through the
wikipedia:operator where most of the data consumers are simply
looking for the operator tag.
I agree this should not happen, but can also be easily fixed by either a
bot or
Dear wikipedia taggers,
There seems to be some doubt as to how the second and subsequent
wikipedia links are handled. Here's an example of the problem:
http://www.openstreetmap.org/way/117544396/history
Of the six versions 2 are initially mapping it and refining the mapping;
the other four
36 matches
Mail list logo