Wikidata:Property proposal/official tourist website

From Wikidata
Jump to navigation Jump to search

official tourist website[edit]

Originally proposed at Wikidata:Property proposal/Sister projects

   Not done
DescriptionOfficial tourist website
Data typeURL
Template parameterItalian Wikivoyage Quickbar parameter: "Sito del turismo" in it:voy:template:QuickbarCity for cities and "Sito" in it:voy:template:QuickbarCountry for Countries
ExampleThis new property will be similar to official website (P856)
Planned useThis information should be centralized and shared within all the language versions
See alsovisitor center (P2872)
Motivation

See m:Wikivoyage/Lounge#Wikidata and official tourist website. Andyrom75 (talk) 14:09, 4 September 2016 (UTC)[reply]

Discussion
Syced, as discussed below with Thryduulf, we'll know for sure country (P17) and official website (P856). Those two data are enough for Wikidata:Notability? --Andyrom75 (talk) 10:55, 14 September 2016 (UTC)[reply]
Having those properties set does not imply anything regarding Wikidata notability. In this context either having a site link to a page at Wikivoyage, or fulfilling a structural need (e.g. being the value of a visitor center (P2872) statement on the item about the place) are the most likely ways that it will satisfy the notability criteria. So, to make sure it doesn't get deleted - make sure that the tiny town has an item first, then create the item for the tourist office, then link the tourist office item from the tiny town item. There are no (at least as far as I am aware) trigger-happy new page patrollers here in the same way that there are at en.wp for example - if you link your new item from an existing one in the same editing session you're very unlikely to have problems. Thryduulf (talk) 14:49, 14 September 2016 (UTC)[reply]
  •  Oppose per Thryduulf. -- T.seppelt (talk) 17:43, 4 September 2016 (UTC)[reply]
  • Thryduulf, T.seppelt, sorry but I'm not talking about a tourist agency, but a government branch, in fact while official website (P856) is for administrative purpose (and stricly linked to any city/country/region) the equivalent for touristic purpose should be positioned at the same level of official website (P856). I don't know how active you are on Wikivoyage, but this is a quite relevant information for this project, while in Wikipedia sometimes is only mention in external links. --Andyrom75 (talk) 22:50, 4 September 2016 (UTC)[reply]
    • It doesn't matter whether the tourist agency is private, a branch of government or otherwise, it's still a tourist agency and it's still the official website of the agency so there is no need for a separate property. How it is represented on Wikidata doesn't impact how prominent it is on Wikivoyage, it just changes where the template needs to look it up from. Thryduulf (talk) 22:56, 4 September 2016 (UTC)[reply]
    • I agree. I made the Quickbar module on enwikivoyage. It really doesn't matter whether the information is stored on the main item (about a city / country) or on the item about the agency itself. Thr latter is in fact more structured and helps at the end even Wikivoyage because it's easier to extend it. If you need help with writing lua code which gets statements from secondary items, please contact me. I'd like to help. --T.seppelt (talk) 05:15, 5 September 2016 (UTC)[reply]
      • Thryduulf, T.seppelt, so what you say is that all the Wikidata instances relvant to countries, cities, etc. should have the property visitor center (P2872), and the Official tourist website should be stored inside it, in this way (for example) starting from a city I could reach the info though P2872->P856 is it correct?
In the affirmative case, since I'm not expert of wikidata, could you confirm me a couple of things:
  • My main concern is: since the official tourist website is just one, there's a way to force that the allowed value of visitor center (P2872) is just one?
  • When no other info are available can be created an instance of visitor center (P2872) with only the information on official website (P856)? Generally speaking I would also be in difficult to provide a name for that instance.
  • There's a way to check the existence of a link in wikidata in order to link that instance instead of duplicate it?
Once we'll agree "on something" will arrive the moment of the data import, then I'll ask you about it as well. Let me know, --Andyrom75 (talk) 07:10, 5 September 2016 (UTC)[reply]
The tourist office will also have official name (P1448), operating area (P2541) and country (P17). Possibly also parent organization (P749), budget (P2769), etc. and they will meet at least the structural need criterion of Wikidata:Notability. Thryduulf (talk) 09:43, 5 September 2016 (UTC)[reply]
Thryduulf, your answer is related only to my second point, right? In the affirmative case, I agree that I'll know (automatically) the country (P17), but all the other informations are unknown. That said, let me reformulate the second point: When no other info are available can be created an instance of visitor center (P2872) with only the information on official website (P856) and country (P17)?
What about the other two points? --Andyrom75 (talk) 13:11, 5 September 2016 (UTC)[reply]
If all you know is the country (P17) and official website (P856) then that's fine, but when you know more fill it in. I don't understand your first question. For your third, there is a way but I don't know how to do it myself. official website (P856) does have a "unique value constraint" which generates reports of violations - if the same link is used on more than one item that's a good clue that they are probably about the same subject, if they are they can be easily merged so don't worry about that too much. Thryduulf (talk) 20:17, 5 September 2016 (UTC)[reply]
Thryduulf, what I was saying on my first point, is that like one Country has only one capitol and currency, also the official tourist website is just one. Maybe the "unique value constraint" that you have mentioned could help, but according to your suggestion, it should be applyed to visitor center (P2872), otherwise a country (P17) could have more visitor center (P2872), hence a country (P17) could have more official website (P856).
I would try to explain you better the third point. What I meant was: if the official tourist web site already exist, I just link it on wikidata, instead of creating a new instance. But to know if it exist of not, I need a tool that is able to search for it, basically something like Special:LinkSearch, but with the ability of looking for an URL inside the Wikidata stored data. --Andyrom75 (talk) 06:51, 6 September 2016 (UTC)[reply]
I understand your third question - I know there is a way to get a list of all the values of a property that you could search, but I don't personally know how to do it so someone else will have to teach you how to do it. For your first a "unique value constraint" will work to make sure that one country or region has one tourist office. Thryduulf (talk) 15:01, 6 September 2016 (UTC)[reply]
Thryduulf, the "unique value constraint" must be applied in every Wikidata instance (e.g. every Country), or is something that can be configured "somewhere" and that it would be applied automatically to all the instances? --Andyrom75 (talk) 21:02, 6 September 2016 (UTC)[reply]
Constraints are stored on the property talk page. All uses of the property are compared to the constraints and a report is created (either automatically or by bot, I'm not sure) that lists all the violations for human review. See for example Property talk:P856 and Wikidata:Database reports/Constraint violations/P856. I can't immediately find a help page that explains how constraints work so I can't point you to one now, but I'm going to ask on project chat. Thryduulf (talk) 21:14, 6 September 2016 (UTC)[reply]
Thryduulf, is enough to add {{Constraint:Unique value}} in the talk page of the property? In the affirmative case, I assume that the property itself will became unique wherever is used, but according to its use this statmente will be a good or a bad thing. Let me explain. If visitor center (P2872), is used ONLY for the official tourist agency of a toponym, this constraing is correct (for all we have discussed above), but if used (or will be used) to list all the general (not official, maybe infopoint or private/commecial) tourist agency of a city this clearly would be wrong. This second case could be a reality in few years when Wikivoyage would be ready to inject in Wikidata, all its listing (hotels, restaurants, and maybe also tourist agencies), although maybe at that time we could consider to create another property. I'm just thinking in advance hoping to prevent possible issues. --Andyrom75 (talk) 07:19, 7 September 2016 (UTC)[reply]
If there are multiple tourist agencies covered, then perhaps marking the official one with agencysubject has role (P2868)official tourist agency and/or distinguishing them with different instance of (P31) statements on their items ("tourist agency" / "official tourist agency") would work to distinguish them. However we need input from someone who understands what can be done with infoboxes to be definitive. @pigsonthewing: is more knowledgeable in this regard than I am. Thryduulf (talk) 10:07, 7 September 2016 (UTC)[reply]
Thryduulf, I can grant you that infobox (Quickbar in Wikivoyage) will contain only one value, the official one. The other cases I've mentioned are relevant to what in Wikivoyage we call listing, that is template used inside the text to structure data.
I don't know if using a property inside an instance to mark it as official would work, becuase I suppose that {{Constraint:Unique value}} wouldn't work within "sisters instances", but maybe I'm wrong. I don't know if I have been clear on this point. Let me know, --Andyrom75 (talk) 07:54, 8 September 2016 (UTC)[reply]
I don't know the answer, sorry. Thryduulf (talk) 15:03, 8 September 2016 (UTC)[reply]
Ok, let's wait for the expert answer. By the way, having a new property with a unique constraint to be added directly to the main instance would be much more easier. Don't you think that would worth to think again on its introduction? --Andyrom75 (talk) 20:55, 8 September 2016 (UTC)[reply]
I am certainly not opposed to this property, since the info must be stored somehow, but the proposed solution seems to be better. Looking for more input.--Ymblanter (talk) 11:11, 5 September 2016 (UTC)[reply]
  • Maybe some numbers would be helpful. If you currently have 100000 such websites at Wikivoyage, but only more information on 100/1000 tourist offices, use of a new property would be more efficient. visitor center (P2872) was propose/created to help include data from Wikivoyage: if this approach works better instead, use this.
    --- Jura 12:00, 5 September 2016 (UTC)[reply]
Jura once fully filled, we should have around 200 national tourist officies (1 for each country) and a huge number of "local" tourist officies (1 for each State, cities, parks, archeological sites, etc.). Each one of them should be linked "1 on 1" with the toponym. --Andyrom75 (talk) 13:12, 5 September 2016 (UTC)[reply]
My understanding of the suggestion is indeed that a tourist site of say a city is by definition a website of a tourist office of this city, even if the office itself is not existent (say has no address, no opening hours etc).--Ymblanter (talk) 17:17, 5 September 2016 (UTC)[reply]
  • I had a look in the listings file from French Wikivoyage, it seems it has about 300-400 entries for tourist offices. Any idea about the number of "official tourism website only" links?
    --- Jura 10:49, 6 September 2016 (UTC)[reply]
Jura, if you are referring to the currently stored ones in it:voy, those are easily countable, if you are referring to the existing ones (over internet) is a huge number, as previously said, almost every city and country has one, and most of the national parks, main archelogical sites, relevant region, etc. have one too. --Andyrom75 (talk) 14:21, 6 September 2016 (UTC)[reply]
For more specific "venues" (e.g. national parks, main archelogical sites you mention), I don't think it's worth differentiating. For the others, the question is if there are that many that it's worth doing a separate item or not.
--- Jura 10:14, 7 September 2016 (UTC)[reply]
Jura, the answer to your question is yes, it definitely worth, just like worth to have official website (P856) for every toponym. Most likely they are in the same number. Where exist an administrative official website, is possible to create a tourist official website to promote tourism in that area. As explained, while for Wikipedia is more important the first one, for Wikivoyage is more important the second one. For example the Italian Wikivoayge has decided to show both in Regions (e.g. voy:it:Toscana) and cities (e.g. voy:it:Firenze). --Andyrom75 (talk) 08:04, 8 September 2016 (UTC)[reply]
One problem is that the "tourist agencies" you are talking about here are not always separate organisations, with separate websites. The tourist information of my municipality is just some disks with booklets that can be collected at the municipal reception. It is the same place where I go when I have urgent mails who need attention. It is the same place I go when I need to talk with some of the office holders in the municipality. -- Innocent bystander (talk) 14:15, 7 September 2016 (UTC)[reply]
Innocent bystander, correct, those locations are a lot and not directly linked (1 on 1) to the official web site of a toponym (tipically a city). In some cases they have a dedicated website but in others don't. Usually those officies are use for administrative purpose only but maybe they can serve also for tourist purpose. In any case is necessary to find a way to distinguish the official tourist website from all the other sites (regardless where we decide to store this information). --Andyrom75 (talk) 11:25, 8 September 2016 (UTC)[reply]
Yea, this is currently the main tourist page of my Municipality. It used to be more inviting that it is today. Now it is more of an invitation to a special page designed in cooperation with three other municipalities. The Municipality has several subpages on its web domain. One for each branch of the Municipalities areas of interest, school, social service, culture, environmental control, housing and industries.
I therefor think I  Support this proposal. -- Innocent bystander (talk) 16:59, 8 September 2016 (UTC)[reply]
We need to be able to define a official tourist website, but I believe like Thryduulf that having an item for each tourist office is a best structure. So, problem solved, we can start using that right now :-) Having an item allows us to add the tourist office's name in different languages, alternate name, address, phone, latitude/longitude, in addition to its website. Example data: https://en.wikivoyage.org/wiki/Kawagoe#Understand -> Kawagoe Tourist Information Office (Q26904724) Thanks a lot for launching this discussion! Syced (talk) 16:04, 16 September 2016 (UTC)[reply]
Syced, since a toponym can have more than one visitor center (P2872), do you know how can one and only one of them be set as official? --Andyrom75 (talk) 22:13, 16 September 2016 (UTC)[reply]
In case there are several, the official is the only one which has the city as a value for operator (P137). I updated Kawagoe Tourist Information Office (Q26904724) as an example of that. Let us know if you need help with the SPARQL, cheers! Syced (talk) 05:23, 17 September 2016 (UTC)[reply]
Syced, since there's only one official toursit website, there's a way to force its unicity? I mean, a single property can be set as "unique value constraint", but being this a "property of a property" I was wondering how we can do. Any idea? --Andyrom75 (talk) 08:05, 17 September 2016 (UTC)[reply]
I don't think it can be enforced via a constraint, but I don't see this as a huge problem. We could have a SPARQL request that checks that and run it from time to time? Or if there are more than one we can output an error, and it will be promptly fixed. Cheers! Syced (talk) 13:03, 18 September 2016 (UTC)[reply]
Where would you show the error to be promptly fixed? The example you shown in the article is a generci listing, so it shouldn't be suppose to generate an error.
Another thing that I was thinking. Ok the idea of using a property to indicate the officiality of a web site, but do you think that operator (P137) would be the more intuitive? PS I haven't think on something else, I'm just brainstorming with you. --Andyrom75 (talk) 07:16, 19 September 2016 (UTC)[reply]
The easiest thing to do is probably have different items for "tourist office" and "official tourist office" (or s/office/agency/ etc) for use in the instance of (P31) statement about the office/agency. The official tourist office item would be a subclass of tourist office, so it wont be a problem with the constraints. The other (or additional method) would be to add a has characteristic (P1552) statement noting it's official status, either on the item or as a qualifier to the visitor center (P2872) statement. Thryduulf (talk) 09:31, 19 September 2016 (UTC)[reply]
Whatever we end up choosing, we would better write a guideline page about it :-) Syced (talk) 23:37, 19 September 2016 (UTC)[reply]
Syced, totally agree with a guide in any case :-)
Thryduulf, if I've understood correctly you suggest to use (e.g. for a city) two properties: one official that will be unique, and the other "generic" that can have multiple values. The first one is an instance of (P31) the second one. In this way I think that sounds good, enough easy to be implemented in an article and pretty intuitive to be filled by a Wikidata editor.
Question: being a subclass, it must follow in any case the new property process or there is a different process to follow for its "bless"? --Andyrom75 (talk) 07:54, 20 September 2016 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I think you've misunderstood slightly. My suggestion is as follows:

⟨ Example City ⟩ visitor center (P2872) View with SQID ⟨ Example City official tourist office ⟩
visitor center (P2872) View with SQID ⟨ Example City unofficial tourist office ⟩
visitor center (P2872) View with SQID ⟨ Example city very unofficial tourist office ⟩
⟨ Example City official tourist office ⟩ instance of (P31) View with SQID ⟨ official tourist office ⟩
official website (P856) View with SQID ⟨ example.com ⟩
⟨ Example City unofficial tourist office ⟩ instance of (P31) View with SQID ⟨ tourist office ⟩
official website (P856) View with SQID ⟨ example.net ⟩
⟨ Example City very unofficial tourist office ⟩ instance of (P31) View with SQID ⟨ tourist office ⟩
official website (P856) View with SQID ⟨ example.org ⟩
⟨ official tourist office ⟩ subclass of (P279) View with SQID ⟨ tourist office ⟩

The other alternative is:

⟨ Example City ⟩ visitor center (P2872) View with SQID ⟨ Example City official tourist office ⟩
has characteristic (P1552) View with SQID ⟨ official tourist office ⟩
⟨ Example City ⟩ visitor center (P2872) View with SQID ⟨ Example City unofficial tourist office ⟩
⟨ Example City ⟩ visitor center (P2872) View with SQID ⟨ Example City very unofficial tourist office ⟩

As "official tourist office" is an item, there is no proposing that needs to be done, it can just be created. Thryduulf (talk) 11:45, 20 September 2016 (UTC)[reply]

Thryduulf, in this case the unicity issue still persist, however I think is more intuitive adding this subclass than adding the city. Between the two proposals I think the first one is better because being "offcial" is a status of the tourist office itself and not a characteristic of the link between the city and the office. I'm start thinking that without a new propery is impossible to set it unique. --Andyrom75 (talk) 20:13, 20 September 2016 (UTC)[reply]
I'm sure someone could write a report to flag any locations with more than one official tourist office - something like comparing all the values of operating area (P2541) on instances of official tourist office and generating a list of any that are not unique would probably work, and maybe even possible as a complex constraint (I don't know). However, it may be better to just code the template to allow multiple official tourist offices as this will not break down when there are different offices, e.g. catering to domestic and foreign tourists, business and leisure tourism, urban and rural areas, etc, etc. Thryduulf (talk) 08:53, 21 September 2016 (UTC)[reply]
Thryduulf assuming approved your first proposal, where should be written the guideline page mentioned by Syced and who can take it in charge? --Andyrom75 (talk) 14:59, 21 September 2016 (UTC)[reply]
Anyone can take charge! As you seem to be the most interested in working on this, you would probably be the ideal person. As for where, I don't know - if there is a Wikivoyage coordination space then that would seem good, but anywhere in the Wikidata: namespace should be fine, it can always be moved if needs be. Thryduulf (talk) 19:52, 21 September 2016 (UTC)[reply]
Andyrom75, I let you formalize the decision at Wikidata:Wikivoyage/Resources#Tourist_offices. Cheers! Syced (talk) 04:40, 22 September 2016 (UTC)[reply]
Thryduulf, in your first example <official tourist office> and <tourist office> are two already existing Wikidata instances?
Syced, thanks for the link. I'll try to write a draft but I would prefer that someone else would refine it. :-) --Andyrom75 (talk) 22:01, 22 September 2016 (UTC)[reply]
I don't know. If they don't exist yet, just create them - you don't need to propose items. They're clearly needed for structural uses so there is no issue with notability. Thryduulf (talk) 22:52, 22 September 2016 (UTC)[reply]
We have already Q24175078--Ymblanter (talk) 19:52, 23 September 2016 (UTC)[reply]
Ymblanter, Thryduulf, I've created in the Q26989327 in the same spirit of Q24175078, with the link mentioned in the first example
⟨ official tourist office ⟩ subclass of (P279) View with SQID ⟨ tourist office ⟩
. Is it ok? --Andyrom75 (talk) 20:27, 23 September 2016 (UTC)[reply]
As far as I am concerned this is perfectly fine, though it might not harm in leaving a short note at the talk pages of these two items briefly explaining the difference.--Ymblanter (talk) 20:35, 23 September 2016 (UTC)[reply]
Ymblanter, what do you think about this? --Andyrom75 (talk) 20:50, 23 September 2016 (UTC)[reply]
Great, thanks.--Ymblanter (talk) 20:52, 23 September 2016 (UTC)[reply]
I added also a short description in Talk:Q24175078. Syced, Thryduulf, Ymblanter, please feel free to revise the draft I've written on Wikidata:Wikivoyage/Resources#Tourist_offices. Thanks, --Andyrom75 (talk) 21:19, 23 September 2016 (UTC)[reply]
Once done a bot operation is needed to reverse on wikidata the information present in it:voy:. Any suggestion on who can support it? --Andyrom75 (talk) 21:19, 23 September 2016 (UTC)[reply]
The best thing to do is to ask at Wikidata:Bot requests, being specific about what you need the bot to do. Thryduulf (talk) 13:33, 24 September 2016 (UTC)[reply]
Thryduulf, I've created Wikidata:Bot_requests#Official_tourist_website, since you already know the topic and how clear the request should be, please check it and tune it in case of need. Thanks, --Andyrom75 (talk) 20:13, 24 September 2016 (UTC)[reply]

I think this can be closed as "not done" or "withdrawn" as an alternate modelling is being progressed that does not require this property. Thryduulf (talk) 14:45, 4 November 2016 (UTC)[reply]

Andyrom75, let's clean up and enrich the existing tourist offices now :-) Syced (talk) 05:24, 30 November 2016 (UTC)[reply]
Syced, thank for the ping. I've already checked a big amount of webiste both in Wikivoyage and Wikidata. I still miss the ones in this category before give the greenlight to a Wikidata bot operator. If you have same spare time, please help on cleaning the info. Feel free to write me for further details.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/official_tourist_website&oldid=412540210"