About this board

Logo of Wikidata

Welcome to Wikidata, Swpb!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

  • Introduction – An introduction to the project.
  • Wikidata tours – Interactive tutorials to show you how Wikidata works.
  • Community portal – The portal for community members.
  • Contents – The main help page for editing and using the site.
  • Project chat – Discussions about the project.
  • Tools – A collection of user-developed JavaScript tools to allow for easier completion of some tasks.

If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards! Please, never create any items for any userpages or subtemplates. Liuxinyu970226 (talk) 13:12, 27 October 2014 (UTC)

Previous discussion was archived at User talk:Swpb/Archive 1 on 2016-01-05.

MediaWiki message delivery (talkcontribs)
Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-05-06.
Translations are available.

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

  • Wikidata periodic table - Tool by User:Ricordisamoa, to browse all chemical elements available on Wikidata, with atomic number, chemical symbol, and localized label. It also includes two charts of the nuclides, with links to every isotope in Wikidata, colored by half-life or decay mode.

Other Noteworthy Stuff

  • A new UI mode is available for the online validator for EntitySchemas. It represents validation reports as a table rather than a very long string, and replaces most links with hyperlinks with some of the text behind them; making them easier to read. Currently being tested at https://shex-validator.toolforge.org/packages/shex-webapp/doc/shex-simple-improved.html, we are looking for participants to evaluate this tool. Some experience with editing Wikidata is appreciated, but no experience working with Schemas is required. If you are interested, you can sign up here. We hope to begin interviews around May 13. For more details, visit User:M.alten.tue

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • We attended the Wikimedia Hackathon.
  • REST API: We are finishing the route for creating an Item (phab:T342990) and modify the data of a Property (phab:T347394)
  • EntitySchemas: We are continuing the work on creating the new datatype to link to EntitySchemas in statements (phab:T214884)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

· Unsubscribe · Help translate · MediaWiki message delivery (talk) 11:00, 7 May 2024 (UTC)
Reply to "Wikidata weekly summary #626"
MediaWiki message delivery (talkcontribs)
Reply to "Wikidata weekly summary #625"

Why are you removing well referenced statements?

15
Olea (talkcontribs)

Hi:

I see you are doing a massive modification of Spain locations like this. Why are you doing this? Would you please undo the changes?

Thanks.

Swpb (talkcontribs)

The problem is that the statements, though referenced, are wrong, and lead to incorrect inferences. Q112876870 is not a field name, it is a place. (field name (Q1434274) has been somewhat conflated for a while, but it originally and overwhelmingly is labeled as referring to a kind of place name, not a kind of place.) Q112876870instance of (P31)field name (Q1434274) results in inferences like Q112876870instance of (P31)noun (Q1084). I will undo the batch for now, and redo it when I work out how to transfer the existing references to the replacement statements.

Olea (talkcontribs)

Thanks for answering. I think I understand your concerns but still I have mine. The source used in this case is Nomenclátor Geográfico Básico de España (Q106767497), which is a big database (more than a million entries) published by a national institution. They use this classification. Then, I proposed this Wikidata mapping schema I've been using (check code 4.2.2). I fully understand the Wikidata's semantic drift phenomenon and I can agree many items should be refined. Now, my concerns are:

  • I can respect your changes for paraje (Q1434274) but now I'm not sure if, for example, the ESwiki sitelink corresponds with the current statements;
  • also, I really don't know if paraje (Q1434274) and paraje (Q98929991) are the same concept (both items shares label «paraje» in Spanish);
  • more, the Spanish word «paraje» is very frequent and I would like to keep it properly mapped in Wikidata;
  • also, your final changes keep the reference (thanks) but the entidad territorial artificial (Q15642541) is too generic so the mapping is suboptimal;
  • finally, I want to keep up to date the gazetteer mapping schema, whatever the item for 4.2.2 should be.

I have almost not idea of designing geography ontologies so I'm not qualified to decide which terms are correct or wrong, but I still want to keep in Wikidata an item compatible with the «paraje» meaning in Spanish and mapped to this gazetteer.

How do you see it?

Swpb (talkcontribs)

Well, I'm not an expert in geography ontology either, I'm just coming at this from the perspective of disjointness violation, where my concern is distinguishing places from names. As "paraje" means "place", it does seem like that label and the ES wiki article fit better with place (Q98929991), or geographic entity (Q27096213), or even a new item to reflect the particularity of the term's use in Spanish-speaking countries, rather than field name (Q1434274). So I support you making that move, and I'd suggest you update your schema accordingly. I also agree that in most cases, places can be classed more specifically than human-geographic territorial entity (Q15642541): for the purpose of semi-automated migration, it was necessary to choose a class that all the items would definitely belong to, but they can certainly be made more specific individually.

Herzi Pinki (talkcontribs)

Hi Swpb, I also come here for the same reason, i.e. (maybe others). In (Austrian) German a Flurname (Q1434274) denotes a place with unsharp borders, an area with a name. It is not the name, but the area denominated by that name. For me it is the perfect choice. You can tell a local who knows the name and he/she will find his/her way to the place. You can use GIS services to show the Flurname (Q1434274). It is not the name as a separate entity. It is a named entity, like lakes, mountains and persons named John Doe. nicht physiographische gebietsmäßige Einheit (Q15642541) is much too abstract. Removing the type together with the references is just not respecting my work. Please leave the references. On the other hand, the basic problem behind is that as far as my work is concerned, those items have travelled a long way from old maps via geonames via Ljsbot and WP:ceb and via another Bot to Wikidata. And as all this rubbish is not even thought to be deleted, I was trying to make the best out of it. Moving stuff to abstract clouds does not help. Please can you rethink your changes (and undo them eventually) and give me an alternative item I can use instead. best --~~~~

Herzi Pinki (talkcontribs)

there are about 200 occurences of this item now in Austria. Some with an image assigned. If it is just a name, how can you assign images? e.g. Oberer Karlingerboden (Q21859149) (on Austrian map). BTW, the definition of nicht physiographische gebietsmäßige Einheit (Q15642541) for me is contradicting in the English (territorial entity of which the borders are determined by physiographic and human features) and German (Gebiet mit künstlich gezogenen Grenzen = area with artificial borders) version. --Herzi Pinki (Diskussion) 22:06, 5 April 2024 (UTC)

Swpb (talkcontribs)

Sorry, I'm traveling now and limited to mobile. I can take care of this after Wednesday.

Swpb (talkcontribs)

Herzi - The German Wikipedia article on "Flurname" describes it as a type of place name (specifically, a type of endonym (Q1266782)), not the place designated by that name. Obviously, Oberer Karlingerboden (Q21859149) is a place, not a name, so it should not be an instance of field name (Q1434274). The most appropriate parent class for places like Oberer Karlingerboden (Q21859149) or Damberg (Q21873738) would be something like "place designated by a field name". I can certainly create such a Q-item, and point the P31 statements on Austrian places to it (including references).

The question then becomes, what is the appropriate parent category for "place designated by a field name"? You say human-geographic territorial entity (Q15642541) is too "abstract", but I do not see any subclass of it that would encompass all the places that were formerly stated to be instances of Flurname. Maybe you meant that human-geographic territorial entity (Q15642541) is actually too specific, since its German description seems to exclude places with natural borders, such as a landform (Q271669), which Flurname says can be designated with a Flurname? If that's the case, maybe the parent class should be geographic location (Q2221906). It looks to me like the only thing differentiating these places from geographic location (Q2221906) in general is that their names are endonym (Q1266782).

Swpb (talkcontribs)
Herzi Pinki (talkcontribs)

Sorry, I was distorted for a while and not in the mood of engaging here. It seems to be too complicated for me to differ between the place having a name and the place. I don't feel your abstraction. If durch einen Flurnamen bezeichneter Ort (Q125505344) is the answer, we should have such items for all geographical objects having a name (=almost all). As the first and locally coined name is the endonym, we should either have additionally ist ein(e) (P31) = durch einen Flurnamen bezeichneter Ort (Q125505344) for all cities and settlements and mountains etc. or we even should duplicate the whole geographical stuff and separate the object from it's name. Still thinking. In the end I don't know what to assign as ist ein(e) (P31) for objects like Oberer Karlingerboden (Q21859149). When this is a durch einen Flurnamen bezeichneter Ort (Q125505344), why isn't any Berg (Q8502) or any Siedlung (Q486972)? The German translation of durch einen Flurnamen bezeichneter Ort (Q125505344) as durch einen Flurnamen bezeichneter Ort is not identical to the English phrase place designated by an endonym, as Flurname is not identical to Endonym (also existing in de:Endonym), but a subclass (not even sure) thereof. So the German translation should be durch einen Namen bezeichneter Ort. Is this really a useful abstraction? I will consult about the meaning of Flurname in the German WP and come back. Please be patient. best

Swpb (talkcontribs)

So, what kind of place are Keesau (Q21879419), Schneewinkel (Q21859075), etc.? If, as you say, being labeled with an endonym is not a reason to distinguish them from other types of places, then what was wrong with making them instances of human-geographic territorial entity (Q15642541) (or geographic location (Q2221906)) in the first place, as I originally did??? Most can surely be made more specific, like mountain (Q8502) or human settlement (Q486972), but that can be done later and should not be a prerequisite for moving the P31 statements from the incorrect field name (Q1434274) to a correct but not maximally specific class. If you can't give me a distinction between these types of places and other types, I will merge place designated by a field name (Q125505344) up.

Also, I'm not proposing duplication - there should be very few items for place names per se, and those that do exist should mostly be lexemes, not Q-items (see ).

I'm happy to change the English label of Q125505344 to "place designated by a field name" on your assertion that a "field name" or "Flurname" is not the same as an endonym, but I have yet to see what the distinction there is. On the other hand, the distinction between places and place names is inviolable, and conflating them leads to logical absurdities.

Swpb (talkcontribs)

Herzi - Any results from German WP?

Herzi Pinki (talkcontribs)

Yes, my opinion is not shared by anybody in a decisive way. Your design decision to separate the name from the object is the correct one (except my minority vote). Sorry for bothering. durch einen Flurnamen bezeichneter Ort (Q125505344) seems to be perfect. best --~~~~

Swpb (talkcontribs)
Herzi Pinki (talkcontribs)
Reply to "Why are you removing well referenced statements?"
Xezbeth (talkcontribs)
Swpb (talkcontribs)

Can you show me an example? I'm querying values of P123 that are instances of imprint and not finding any constraint violations, which makes sense since imprint (Q2608849) is allowed as a value of P123 by its value-type constraint...

Xezbeth (talkcontribs)
Swpb (talkcontribs)
Reply to "Imprint"
MediaWiki message delivery (talkcontribs)
Reply to "Wikidata weekly summary #624"
SM5POR (talkcontribs)

I saw you had doubts about my ability to express my points in a coherent way, and you may very well be correct in that obsErvaTion. Let me just explain that I don't feel comfortable having wasted your or anybody else's time debating what may well have been a motivated proposal, and I think your stated intention to rElaunch the proposal is a good approach. I'm not sure I should join that discussion, as I don't think I have much To contribute. My current primary area of interest in Wikidata Is the lexeme database,where I'm looking at adpositions in particular. I also invite you to commEnt on that work, which you can find on my [[UserːSM5POR/Languages‘ subpage.

SM5POR (talkcontribs)

UserːSM5POR/Languages#in‘ istheectionwher Idiscuss sssenses ofadpositions.ooPS, i APPARENTLY DON'T knowhow to linktoarbitrarypagesin Wikidata. That is not supposed tobe an edit link.I hopeyou can figure out what I mean by Languages#in

Reply to "Objects of transfer"
MediaWiki message delivery (talkcontribs)
Reply to "Wikidata weekly summary #622"
MediaWiki message delivery (talkcontribs)
Reply to "Wikidata weekly summary #623"
MediaWiki message delivery (talkcontribs)
Reply to "Wikidata weekly summary #622"

Interface, means, and cause classes

2
Daask (talkcontribs)

I removed the claim that means (Q12774177)subclass of (P279)cause (Q2574811), which I acknowledge was rather reckless and left Wikidata's class hierarchy in an undesirable state. Frankly, I didn't know what the appropriate superclass was then, and I don't know now.

Let's consider some of means (Q12774177)'s current direct subclasses:

A means, such as a search strategy, is just one way of achieving a goal. It is not the agent selecting or pursuing the goal. It may or may not be necessary for the goal to be achieved or change the outcome. With no change in the outcome or the probability of an outcome, it doesn't seem to me that we have the quality of w:en:Causality. Thus, I'm uncomfortable with the claim means (Q12774177)subclass of (P279)cause (Q2574811).

Separately, regarding the claim: interface (Q110558466)subclass of (P279)means (Q12774177). means (Q12774177) has a quality of functionality or purpose, whereas interface (Q110558466) may just be a point where two systems interact, without necessarily being part of any larger system. It may or may not be functional for either of the two systems which are interacting, thus I think it lacks this quality.

Swpb (talkcontribs)

How about means (Q12774177)subclass of (P279)converter (Q35825432)? A converter (Q35825432) is something that doesn't necessarily cause, but can cause.

And for the latter claim, how about interface (Q110558466)subclass of (P279)object (Q488383)? It may be hard to get more specific than that.

Reply to "Interface, means, and cause classes"