Wikidata

Wikidata:Requests for comment/VCards for Wikivoyage

< Wikidata:Requests for comment


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
  1. Type of listing: instance of (P31)
  2. Alternative name: alias if can be queried
  3. URL: official website (P856)
  4. Email: email address (P968)
  5. Address: P969 (P969)
  6. Phone, fax, checkin time, checkout time, price: discussing in Wikidata:Property_proposal/Sister_projects#Wikivoyage

--GZWDer (talk) 09:24, 23 November 2013 (UTC)[reply]

General ideas

edit

Wikivoyage has a lot of entries about sights, hotels, train stations.... de: call them VCard, en: call it listings. All these objects should go to Wikidata and being presented in the articles by using a tag or something. Maybe we can map out the structure/content of this object here. I hope its the right place and not running already on a different site. -- DerFussi 05:24, 9 August 2013 (UTC)[reply]

Links:

Structure

edit

That's a first idea what we may need

  • Location (Is in Administrative unit) - to identify which Wikivoyage page this should end up on.
  • Name (maybe twice, as a multilingual Label and the object's local language - to show it the taxi driver in e.G. Bangkok)
  • address (maybe bilingual as well)
  • directions (contains the description, if there is no address or a detailed description of the place, e.g. 200m after the gas station on the left side. - multilingual text available in any language, (if it is not provided in the wiki's language, the english one will be displayed or other fall back language as determined by the wiki)
  • Personalised description/review sourced to a username - multilingual text.
  • longitude, latitude, altitude
  • 'instance of' 'Wikivoyage listing' - a picklist (hotel,sight, monument, train station, museum, spa, beach, gallery .... each maybe connected with a specific icon presented in the article or map - so we can search wikidata and identify which items have wikivoyage listing info.
  • phone number
  • mobile number
  • fax (meanwhile outdated?)
  • email
  • email2
  • url
  • hours (for opening ours, check in/out time)
  • price (entry fee, room rate)
  • accepted crdit cards
  • facilities - various values that each represent an icon, e.g. the following
    • no barriers
    • WiFi
    • pets allowed
    • gayfriendly
    • bed & bike

Comments

edit
  • I think V-cards can just be stored with their Q-item using existing/pending properties. --Tobias1984 (talk) 08:07, 9 August 2013 (UTC)[reply]
  • In principle, this is an idea worth of consideration. However, we clearly have some information in the listings (V-cards) which is subjective, like for example quality of a restaurant or general interest of a museum. In addition, this info is not only subjective, but also is in different languages. We need to discuss how we solve this problem (for example, by excluding this info and letting every project to add them separately).--Ymblanter (talk) 08:58, 9 August 2013 (UTC)[reply]
Subjective information can be included provided it is labelled as such by (for instance) being attributed to a particular username. Filceolaire (talk) 21:22, 9 August 2013 (UTC)[reply]
The subjective information (information in the content= field) is not necessarily added by just one person--it is a collaborative effort. But yes, sharing listings data between our projects would be hugely, hugely useful, and is a real priority for Wikivoyage. --Peter Talk 05:50, 10 August 2013 (UTC)[reply]
  • While shared data would be great for addresses, URLs, phone numbers, etc, I would be concerned if the listing data was not editable on the individual language versions of Wikivoyage after being moved to Wikidata. If casual editors cannot update phone numbers and URLs on Wikivoyage then it would be a significant usability problem, although if there was a way to pass-through Wikivoyage edits to the underlying Wikidata structure then my concern is irrelevant. -- Wrh2 (talk) 05:52, 10 August 2013 (UTC)[reply]
I agree that an 'edit-in-place' tool will be well worth developing. In the meantime a link to the relevant Wikidata item should be enough to get us started. Filceolaire (talk) 09:39, 10 August 2013 (UTC)[reply]
  • I am not sure it is worth the effort. Which information are we going to store and update? Addresses? But they are written in different scripts (Latin and Cyrillic). Working hours? They again entail days, which are language-dependent. Prices? Comments to prices are language-dependent as well. Weblinks? But different Wikivoyages have developed different policies regarding the links to Facebook, Twitter, etc. The only straightforward and language-independent information would be the phone numbers and e-mail addresses, but do they change often enough to justify the whole effort?
Finally, I can't envisage a simple procedure of removing closed listings. Removing data items from Wikidata requires a special procedure. We could tag places as "closed", so that they would not appear in any Wikivoyage pages any longer, but this would make Wikidata a place to store lots of outdated and unnecessary information. --Atsirlin (talk) 08:49, 10 August 2013 (UTC)[reply]
An object can have several labels (the name and address in the language you need). The name/address is not limited to English or whatever. Even a fallback is available. If the address is not available in e.g. Russian, the English one is displayed. I am sure we will urgently need these information here. Every phone number is redundant in every wiki now. Data with units are convertible. You will get the time in the suitable unit and format you need. Items are not displayed automatically. You don't have to close an object. Every wiki just has an ID list of items to be displayed in their article. One more advantage could be that a map of all available items can be provided. If an article in my language does not exist, and I need a hotel I can access the Wikidata map, containing all objects. -- DerFussi 09:28, 10 August 2013 (UTC)[reply]
Days of the week (for instance) will be links to wikidata items which already have their labels translated into multiple languages. If your language isn't one of them then a half an hours work and you can translate them once and then they are in your language on every listing item Filceolaire (talk) 09:42, 10 August 2013 (UTC)[reply]
Yes, I understand that each small piece of information (like day of the week or currency symbol) can be stored in different languages and then used in an automated manner, but I am not sure that we can easily combine them into complex "expressions" (here is an example of typical opening hours for an enterprise in Estonia: M-Th 11-21, F-Sa 11-1, Su 12-19), keep favorite format for each language version (English Wikivoyage had amazingly long discussions on "AM" vs. "am" and other minor details of the format), and still have the whole thing simple and feasible for a general user.
More generally, I see a big advantage of Wikidata in storing unique pieces of data, like the number of residents in a city. I change one number, and it is changed across all projects. If we start storing language-specific information, we end up in a situation when I have to go through all languages and update the information (same as now). But I don't know these languages, so I eventually update the information in my own language + English, and the rest becomes outdated.
Of course, I am not against this proposal. If you guys are bold enough to try this, please, do it. However, it may be more difficult than it looks from outside, and we should definitely refrain from spreading information in languages, which are foreign to each language version. Otherwise, we should simply shut down all branches of Wikivoyage and focus on improving the English site. --Atsirlin (talk) 22:23, 12 August 2013 (UTC)[reply]
  • Fallback to another language is problematic as it could create a mess of English-language listings in non-English WV guide pages. For instance, my hometown has a good article on en: but the fr: version has no food/drink listings yet. A third-language version is little more than an outline or stub. Any fallback scheme would provide the town's history in French and the things to see and do, then inexplicably switch to English halfway through the page. The result might actually look worse than what's there now. K7L (talk) 10:34, 10 August 2013 (UTC)[reply]
Only the multilingual sections would revert to the fall back language and we can put a 'translate' button next to these to encourage contributions. Filceolaire (talk) 16:08, 10 August 2013 (UTC)[reply]
  • None of the fields except for email, phone number, and lat/long are as simple as implied above. In addition to the description field, all of the others, including hours, prices, alt, directions, etc. often contain snippets of prose, and even when they don't, they are subject to a wild variety of formats. Unless we are going to get in the business of machine translation and start honing complicated heuristics, it's simply not going to be possible to automatically translate any of those in any reliable way.
  • Having things display in a "fallback" language is not going to be acceptable at all. It could literally fill the non-English versions with many times more listings in English than they have in their own languages. I don't think en: would accept having its Russian destinations suddenly get a crap-ton of listings in Russian or its Japanese articles suddenly getting a whole bunch of listing in Japanese. Similarly, the other versions are not going to appreciate having a giant influx of English or other languages mixed in either.
  • Even if translation were not a problem, we can't have listings automatically show up in all language versions, because we limit and prune the number of listings in each section - we curate the lists and specifically avoid being like a telephone directory with long lists. Every version prunes, arranges, and subdivides its lists differently, and discussions about how and when to do that take place locally, in the language of the respective version. If we suddenly all shared listings, those lists would have to be maintained centrally, and probably in English, taking away much autonomy from the non-English versions whose contributors may not be capable of joining such conversations.
  • As a corollary to the previous point, not every version is looking for the same list. Hebrew and Arabic versions may tend toward or away from certain restaurant listings, for example. And though I know we don't currently have a Japanese version, we may at some point, and the average travel-style for Japanese tends heavily toward availability of Japanese food, all-inclusive resorts, tour packages, and hotels where Japanese is spoken and/or which cater specifically to Japanese tourists, and obviously it doesn't make sense to share that approach with the other versions. I am certain there are similar things for other language versions as well. When it comes to the nature of the specific places recommended, we cannot have a one-size-fits-all approach.
Overall, I am not very convinced of the necessity or utility of this proposal. I think it would be very very complicated to implement workably, with only very marginal benefit in return. Texugo (talk) 18:16, 10 August 2013 (UTC)[reply]
  • Not all listing templates on various sites conform to each other; not all articles use any form of listing templates at all; there may be subjective and/or selective issues as to content; would entail lots of editorial work and other complicated measures. It seems to me that the horse is already out of the barn so-to-speak... I tend to agree with comments above. Matroc (talk) 21:20, 10 August 2013 (UTC)[reply]
I doubt that more than 10% of all the listing that wikivoyage will eventually have are created yet so I don't think the horse has bolted. If a suitable tool is created so that whenever an item is created in Wikivoyage it is automatically added to wikidata and imported back into wikivoyage, then as each wikivoyage grows it will automagically be integrated with wikidata and with other language wikivoyages.
  •  Support Though I might agree on the point that not all data could be imported to Wikidata (because the relative property type is not ready yet, or because the data are really difficult to manage), I do think that some of those data can be imported here - at least for the main attractions of a place, such as natural reserves, museums, monuments, and so on. As Andyrom said, it's just a matter of deciding the details. Sannita - not just another it.wiki sysop 03:07, 11 August 2013 (UTC)[reply]
It shouldn't be that hard to make sure that all info added to wikivoyage in future is wikidata compatible. Filceolaire (talk) 15:27, 12 August 2013 (UTC)[reply]
Each listing is tied to a local administrative district. Each wikivoyage can specify what districts it covers and then choose from the available items which are shown on their pages (with a 'show other languages' link?) Filceolaire (talk) 15:27, 12 August 2013 (UTC)[reply]
Why? Each listing has an ID. Just place a template using the object id to your article. And that's it. There is no necessary relation to any WV article/destination. Just something like {{WDVCard|id=foo|desc=Your local description text}} would add it to your article. If you use LUA you can pick the information that you want and how it is displayed time/date format, even using specific exchange rates for currencies. -- DerFussi 07:37, 18 August 2013 (UTC)[reply]
  • What happens to listing/item/vcard fields which exist in one version of Wikivoyage but not another? The wikipédia= and facebook= links on fr: and others don't exist on en: (a WP field in listings was proposed but a Jan 2013 discussion hopelessly deadlocked) and, even if they did exist, the target needs to be WP in the same language. K7L (talk) 13:21, 11 August 2013 (UTC)[reply]
All the info will be on wikidata. The various wikivoyage versions will decide for them selves which data to display and which to ignore. Filceolaire (talk) 15:27, 12 August 2013 (UTC)[reply]
  •  Support Very needed. Addition: Some listing (typically museums stadiums beaches attractions) already have a Wikipedia page and Wikidata item which contains latitude/longitude. We should link to the Wikidata item, and reuse its latitude/longitude information (currently all such lat/lon info is duplicated between Wikipedia and Wikivoyage). Nicolas1981 (talk) 02:45, 12 August 2013 (UTC)[reply]
  •  Support Great idea and IMO very much needed, especially for smaller WVs. The idea could greatly reduce workload, enrich smaller WVs and to some extent reduce spam/unfair advertising and make Vcards more reliable and trustworthy. There are some technical problems as noted above but I hope that they can be overcome. Kpjas (talk) 08:44, 12 August 2013 (UTC)[reply]
  •  Support It might help to maintain automated lists of museums, historical places, etc. and keep them updated more easily (if shared through all languages there will be more potential updates). I am not so sure about including the email without some kind of protection against mass harvesters. And prices and opening times information should always include "point of time", since it is quite likely that it changes often.--Micru (talk) 17:23, 12 August 2013 (UTC)[reply]
  • Very strong  Support -- Put as much information as possible into the object. It can be used by Wikipedia as well (Churches, museums, temples...). Lua templates can pick and format the information as needed in the project (WP or WV). Just think about local names. E.g. a Chinese temple. The local name written in Chinese can be important (just to show it to the taxi driver). But who should type all the names to all the WV language versions. Most of us have no Chinese keyboard and even can not do it. We even have no Chinese version to copy it from. But Chinese friends can easily help out by typing it in here. -- DerFussi 01:32, 18 August 2013 (UTC)[reply]
  • I  Support this, providing that all the issues discussed above can be worked out. The great and obvious benefit would be the sharing of information between different Wikivoyage versions and beyond (as DerFussi states above, Wikipedia could also use the information, for example). The potential drawbacks (and I may be misunderstanding this) could be the lack of local-language information in particular Wikivoyage or other Wiki projects. I suspect I misunderstood that. This does seem like a good initiative if it can be done right. Ikan Kekek (talk) 19:05, 4 November 2013 (UTC)[reply]

What can be done now

edit

We have heard this week that Phase 2 will be soon available at Wikivoyage, which actually makes the question very much practical. Let us discuss what can be kept centrally from the technical point of view having in mind existing facilities available at Wikidata? What comes to my mind is

  • Coordinates;
  • Phones (as strings);
  • Links to external websites;
  • Prices?

Anything else?--Ymblanter (talk) 17:01, 17 August 2013 (UTC)[reply]

Coordinates of individual objects are fine. However, we need a separate field for geographical coordinates of cities and other destinations, because our coordinates are adjusted for generating proper dynamic maps. It will be a pity to loose all these precise positions by simply taking coordinates that are already available at Wikidata.
What about suggesting a property "entrance coordinate" or a qualifier "type of coordinate"?--Micru (talk) 18:40, 17 August 2013 (UTC)[reply]
If you choose qualifiers, I would rather use applies to part (P518) than create a new ad hoc property. There is a related disccusion on Property proposal/Place. --Zolo (talk) 18:55, 6 December 2013 (UTC)[reply]
Phones: while we can use simple strings, Russian Wikivoyage has introduced a special phone template that separates the country code, area code, and the number itself. Once again, it will be a pity to loose this information. At the moment, we do not take advantage of this separation, but in the future we can easily drop all country codes or change the format of phone numbers at no cost. Other language versions are not using this template and perhaps will not start using it in the nearest future.
country calling code (P474) and local dialing code (P473) already exist. If necessary another one for the area could be created.--Micru (talk) 18:40, 17 August 2013 (UTC)[reply]
Prices: entrance prices can be written in a language-independent way, although we sometimes mention family tickets and other special offers that should be explained explicitly and in different languages. Restaurant and hotel prices are always language-dependent.
I would recommend to wait for the number datatype and use currency (P38) as qualifier. It should also be possible to store periodically the exchange rates and offer the price in the currency that the user wants.--Micru (talk) 18:40, 17 August 2013 (UTC)[reply]
Fax and e-mail can be taken from Wikidata, but those fields are of low importance
Addresses should work for countries with Latin characters, unless people in different language versions are too adamant about the format.
However, none of those are going to be available next week, because we will need the connection to different elements of Wikidata. As far as I understood, phase 2 (or first part of phase 2?) means that we get access to elements of a single card that is already connected to a Wikivoyage article. --Atsirlin (talk) 18:25, 17 August 2013 (UTC)[reply]
Regarding the "addresses", I would use the "monolingual text" datatype once it is available.--Micru (talk) 18:40, 17 August 2013 (UTC)[reply]
If is possible adding automaticaly the date of information insert Rippitippi (talk) 22:42, 17 August 2013 (UTC)[reply]
I think, most important should be a relation between type and geografic coordinates. Benefit of such a database could be not only to store some v-cards structured geografically. In another way, users could search for some types in a certain region, maybe in a later version (My favourite example: Look for all stored types=market in region Andalusia). Furthermore types are relating attached information according to the structure of any wiki-article.
Such typecast currently exists unfortunately in two different variations in german and english Wikivoyage. To find a compatible way to use and advance both typecasts i made a first approach for a synthesis on my german Disksite in WV. (see proposals for development there).
This approach intends a double numerary encoded structure of possible types (01..99), which is deduced from the existing typecasts. Such a codescheme could be easily translated in other languages by theirselves, while the structured intention remains valid on all wikis. Within the suggested table remains enough space to integrate possible culture-bound gaps or other voids, which may grow from a more wikiwide sight of possible locations than the voyagers have.
Regarding a certainly different currentness of stored data a timestamp of last change should be helpful for users.--Gastromartini (talk) 00:17, 20 August 2013 (UTC)[reply]

Display in articles and relation to WV objects/articles

edit

After reading some comments I think, we have different views to the listings. So I just want to talk a bout one of the basics here.

  • As I think there is no need for any relation to an object/article/destination on WV.
  • So object can not be displayed automatically in the articles - and should not be. Each community decides, where, how and how often it is displayed. just by using it. E.g. the Eiffel Tower in the articles about Paris, the quarter of Paris, France and the topic article: What to see before you die.
  • Each listing has an ID. Just place a template using the object id to your article. And that's it. There is no necessary local relation to any WV article/destination. Just something like {{WDVCard|id=foo|desc=Your local description text}} would add it to your article. If you use LUA you can pick the information that you want and how it is displayed: time/date format, even using specific exchange rates for currencies by using a sub template in your wiki. So even Wikipedia, Wikibooks, Wikiversity can use it. Their template will leave out unnecessary information like the phone numbers.

The most important point is to avoid redundant information in each of our some hundred WMF wikis. An only one update (address, phone number, or the simple information whether it's closed/put down) changes all articles.

Am I wrong by thinking that way? -- DerFussi 08:01, 18 August 2013 (UTC)[reply]

Stefan, you are thinking the right way, and your proposal is feasible. The question is how we can develop an interface that will be simple enough for a regular contributor, yet taking into account all subtle details of different languages. Take phone numbers. They break down into the country code, area code, and the number itself. Moreover, we can have several phone numbers and, alas, we can have comments to phone numbers (e.g., use this number for booking and another number for calling the reception). Technically, we could code a large part of language-dependent information (days of the week, currencies, and even price descriptions like "double room:" or "main dish:"), but we also have to make this coding comprehensible and easy-to-use.
I think that we should follow Yaroslav's suggestion and start from simple things like coordinates, url's, and perhaps addresses. This first step already requires some technical work and expertise, because we will have to connect Wikidata to the newly developed listings editor. If it works out, step 2 could be the currencies and language-dependent information. --Alexander (talk) 08:26, 19 August 2013 (UTC)[reply]
I hope to understand Stefans intentions well. At the end would stand a Wikidata-based sort of tool on each wiki-site, which displays users already available (recorded) location informations about his theme (maybe sorted as geografical and/or thematic relation in kontext). Then the user decides itself whether to integrate and, better, update information or not, in idealfall per mouseclick. But whats up with users not too familiar whith such tools? If Wikidata should agree to this project, there is a great responsibility remaining to the wiki-families to overlook and maintain these instruments.
On the other hand: This project could be the headstone for a wiki-based version of places, not only regarding voyagers. So Programmers should define first, which minimum information can be stored without multilangual problems (at minimum location, url, any contact possibility which mostly can be found in url as availible and adress or geodata). Further informations could be offered just as well by linking all sites using the ground informaion.
This way is good use in Commons and could be transferred to this project as well. Each record is listing the informations, which wikidata agrees to maintain. In addition are listed the articles using this record. In this way any user can decide by himself to use further in any wiki given information and has to translate himself.--Gastromartini (talk) 03:28, 20 August 2013 (UTC)[reply]
@Alexander. What newly developed listing editor? .... I have just read an information about it on the summit. Maybe it won't work then. Please check it with the Wikidata guys. That's why I beg, not to develop alone in a language versions. Move it to meta and invite the Wikidata community as well as the WMF technical department. And a message at the lounges of all the other WV lounges would be nice. -- DerFussi 11:51, 20 August 2013 (UTC)[reply]
See here. So far it is a simple replacement for the listing editor available at WT.
To your second note, I think that we simply need more active liaisons who will follow things on meta and perhaps in English/German Wikivoyage, and keep posting news in lounges of their "home" projects. I am sure that many people skip all these boring automatic announcements as long as they are written in English. Translating the news is quite important. Please, don't take it as a personal criticism, though. I just say that the active liaison work is my solution to the problem. --Alexander (talk) 12:08, 20 August 2013 (UTC)[reply]
Sure, but the first step is, to inform the others. After that I'll be able to translate it. I am sure, the listing editor discussion would have attracted some users form de: We are using the template master to provide the forms to be filled out. It's one of the wiki gadgets. And again. Meta is the right place for that. It's multilingual and we are able to provide translated sections, being shown automatically to users. -- DerFussi 03:28, 21 August 2013 (UTC)[reply]
Maybe we should wait till the development team have all the datatypes done and have an edit widget that can be used on Wikivoyage before we start to pursue this further. Lets not get peoples hopes up. Filceolaire (talk) 14:39, 21 August 2013 (UTC)[reply]

Disappearing objects

edit

Objects are built up and sometimes put down. How to handle not longer existing objects? Deleting the object or simply changing a tag from active to historical. As a guy who maintains GIS systems at work I would prefer the last option. Never deleting information . -- DerFussi 08:07, 18 August 2013 (UTC)[reply]

Btw, have you considered having a local wikidata repository for listings? I'm thinking that it would be much easier to manage, and you would have more freedom to create items and properties specific for a tourism related site. In Commons that is how they are going to do it, maybe that could work for Wikitravel too? Use Wikidata when it makes sense (general shared information with Wikipedia), and use the local Wikibase repository for tourist-specific listings (restaurants, attractions, etc).--Micru (talk) 01:22, 19 August 2013 (UTC)[reply]
It can not be shared between thirteen Wikivoyage projects unless installed centrally. Before the launch of Wikivoyage here, we had Wikivoyage Shared (hosting images), which was shut down due to the WMF policy.--Ymblanter (talk) 06:36, 19 August 2013 (UTC)[reply]
Micru: are you sure Commons will have a local database?. Commons will need a lot of links to wikidata items (for creators and for 'image depicts' values) and wikidata will need a lot of links to Commons File: items (to illustrate the wikidata items). They should probably share Properties too - no sense in doing all that localisation twice. I wouldn't be surprised if a new Fspace on wikidata worked out better in the end than doing it on Commons. This applies even more on WikiVoyage, where we are proposing to store the data in the existing Qspace items. Filceolaire (talk) 20:24, 19 August 2013 (UTC)[reply]
Yes, it will be a sort of a mixed system (not entirely as Wikidata) and still somehow connected to WD. I don't know the specifics, but you can ask in the talk page of the proposal page, or in WD:DEV.--Micru (talk) 14:16, 20 August 2013 (UTC)[reply]

Interface

edit

I am sure there are some concerns about the interface. Some contributors may think it's too difficult. Of course there wont be a simple "add listing" button at every section. But I am sure it will come sooner or later. Like the visual editor is a community based (maybe sometimes slow) developing process. But it would be a huge mistake to reduce the information or even deny the introduction of listings on wikidata just because of some difficulties that may occur in the beginning. Think about the future, thousands of objects in a lot of language versions and projects (not ony wikivoyage). Some people wont find the WD-link. Some user will just write direct in the article. We should live with that, and we will face some cleaning duties.... but I am sure. It's worth. We should drive it forward. -- DerFussi 11:31, 20 August 2013 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/VCards_for_Wikivoyage&oldid=91807808"