Wikidata:Property proposal/University of Washington Campus Map ID

University of Washington Campus Map ID

Originally proposed at Wikidata:Property proposal/Place

   Withdrawn

Description	identifier for a building or other place on the University of Washington campus
Represents	University of Washington Campus Maps (Q106715483)
Data type	External identifier
Domain	item; university building (Q19844914); geographic location (Q2221906)
Allowed values	[a-z0-9\-]+
Example 1	Bloedel Hall (Q98974146) → bld
Example 2	Suzzallo Library (Q7651462) → suz
Example 3	North Physics Laboratory (Q102104671) → npv
Example 4	PACCAR Hall (Q98447438) → pcar
Example 5	George F. Russell, Jr. Hall (Q99248904) → russell-hall
Example 6	Henry Art Gallery (Q5717411) → henry-art-gallery-and-allen-center-for-the-visual-arts
Example 7	Bill & Melinda Gates Center for Computer Science & Engineering (Q106716590) → cse2
Example 8	Union Bay Natural Area (Q7885418) → union-bay-natural-area
Example 9	University of Washington Quad (Q47090840) → lndmk-1
Source	https://www.washington.edu/maps/
Planned use	Will add to existing items and to new items that we create
Number of IDs in source	approximately 500 or more
Expected completeness	always incomplete (Q21873886)
Formatter URL	https://www.washington.edu/maps/#!/$1
See also	Pacific Coast Architecture Database building ID (P6486)
Applicable "stated in"-value	University of Washington Campus Maps (Q106715483)

Motivation

The University of Washington Libraries is creating Wikidata items for many buildings and other places on the University of Washington campus. The online University of Washington Campus Maps (Q106715483) is an interactive website that provides historical information about buildings and features on campus, photographs, and links to websites of the units and departments that occupy each building. UWashPrincipalCataloger (talk) 20:55, 5 May 2021 (UTC)

Discussion

•  Support --Jala360 21:10, 05 May 2021 (UTC)
•  Support --TylerRogers 21:54, 05 May 2021 (UTC)
•  Support Sp!ros (talk) 22:05, 5 May 2021 (UTC)
•  Support I will use this property when creating and editing items for buildings on the University of Washington campus. --Crystal Clements, University of Washington Libraries (talk) 00:24, 6 May 2021 (UTC)
•  Support--Katpaws (talk) 14:44, 6 May 2021 (UTC)
•  Support --Emwille (talk) 17:51, 6 May 2021 (UTC)
•  Support --Pteropotamus (talk) 18:07, 6 May 2021 (UTC)
•  Support --Helianthus74 11:21, 06 May 2021 (UTC)
•  Strong support --Uzundzhovets (talk) 00:02, 7 May 2021 (UTC)
•  Support --imandag 07:37, 07– May 2021 (UTC)
•  Support Parobis1 (talk) 00:04, 8 May 2021 (UTC)
•  Support --Adkmeta (talk) 21:57, 10 May 2021 (UTC)
•  Support, an important property for places.--Arbnos (talk) 16:51, 11 May 2021 (UTC)
•  Oppose given the alternate proposal at Wikidata:Property_proposal/map_URL. --- Jura 06:30, 14 May 2021 (UTC)
• @Jura1: I have removed the example of a building from that other property proposal. And your objection does not make sense to me. That proposal was not centered on the University of Washington, although I used examples for it there and it was one way to link to a map showing places on that campus. But that proposal is for linking to an online map of any place via a URL. This proposal here is for identifiers for places and buildings on one online map. There aren't multiple URLs for this map, but the external identifier takes you to the interactive campus map and the particular entity is circled on the map and a side panel appears with further information about that building or location. These two proposals are not alternate proposals. One is for a URL for any online map. The other is for an identifier that points to a single map with a highlighted place. UWashPrincipalCataloger (talk) 06:58, 14 May 2021 (UTC)
  • You might want to the take the time to re-read what @Thadguidry: wrote there. --- Jura 07:02, 14 May 2021 (UTC)
    • @Jura1: I didn't see @Thadguidry:'s comments until after I responded to yours. I have responded there, but I think something like "official map URL" would be useful on the item for the university to point to the campus map of the university, but this proposal would be used to identify specific buildings and other locations on campus, a different kind of thing. I think this proposal and a revised version of the other proposal could happily coexist. I don't think it would be desirable to use an official map URL property on items for individual buildings. UWashPrincipalCataloger (talk) 07:20, 14 May 2021 (UTC)
      • A mere difference in datatype doesn't justify two properties. You can easily convert one to the other. We shouldn't create "official University of Washington website ID" merely because official websites of that organization have some specific features and could all work with the same URL formatter. --- Jura 07:25, 14 May 2021 (UTC)
•  Oppose - Campus Map (in the name) != Building (in your description). 2 different types. Maybe it makes sense to instead have University of Washington request for an Authority ID for University of Washington in whole? Since the university is active in a multitude of Linked Data efforts and building out their own identifiers in many cross-domains (not just buildings...ask Ben Riesenberg). Then University of Washington could provide a global registry (aren't you folks also working on implementing your own Wikibase?) But if that is too much work on your part, then focusing on the real ask here which is "University of Washington is going to mint and maintain identifiers for important places, buildings, structures, or simply any geographical feature human-made or otherwise, in and around University of Washington's campus"...then I would say let's just rename this proposal to just University of Washington GEO ID. That way if additional databases are made available to hold metadata not only about buildings as you say, but also Sculptures, or any fixed construction (Q811430) or broadly any geographical feature (Q618123) then we should be set. Again, this depends on the level of effort of Linked Data and registries or services that University of Washington intends to build out and the endpoints. Ideally, a single URL endpoint and appropriate formatter URL (P1630) for querying any GEO feature, if that's not too much trouble to work towards? ---Thadguidry (talk) 14:41, 14 May 2021 (UTC)
• Thadguidry As I thought more about this, I could have proposed this as a University of Washington location code or ID. The main point of this proposal was to identify buildings and other places on the UW campus. The identifier happens to point to a campus map that shows the location of the entity on campus, but also provides pictures and information about the place, including date of creation, history, size (area), links to entities that occupy it if it's a building, etc. An example is Savery Hall. The map aspect is important, but it is the code or ID for the entity that is the main point of the proposal. These codes are used elsewhere, such as in course catalogs. So how about we rename this University of Washington place code or University of Washington place ID? UWashPrincipalCataloger (talk) 18:20, 14 May 2021 (UTC)
• UWashPrincipalCataloger So, let me take a big step back and explain a few things, where a few others might not be aware of all the wonderful properties already existing in Wikidata. So, let's talk about Ontology mapping, or simply Linked Data. There are already a few ways to generically link some Wikidata Item/Concept to some URL that also has the same concept of the Item, to indicate with a high degree of confidence that both concepts have the same meaning. All without creating a specific new property just for some customer/client/domain. In Schema.org, we have sameAS. In Wikidata, we have several ontology mapping properties to help. In this case, you would simply just use exact match (P2888). For example, soil (Q36133) is an exact match (P2888) with the concept at URL http://aims.fao.org/aos/agrovoc/c_7156 So, the only reason why we might want to have a new property just for University of Washington would be if we really think there might be lots of queries, or a particular project has a really strong need to ease the SPARQL querying. Otherwise, the querying is nearly the same and still fairly trivial to filter to only the P2888 URLs for only University of Washington domain or some University of Washington URL pattern (see the SPARQL examples for a few). I strongly think the benefits are reversed (using 'exact match') when someone has a list of places or structures in a dataset, some might be University of Washington campus specific...and if that's the case, a user can fetch those all the 'exact match' URLs for a Wikidata Item and enrich their dataset. There is a lot of power in using 'exact match' which both simplifies querying actually, since it's only 1 property to remember! I kind of don't like us to continue to create thousands of external id properties like this proposal where most are essentially just for the purposes of 'exact match' with no justification of a true problem other than just to get around saving 1 more SPARQL FILTER statement. (In fact, you don't describe the problem you currently have other than a property to hold a URL that has semantic equivalency to a topic or concept which also brings along a map for the ride. That's great! But, it's fairly trivial to filter exact match (P2888) statements by subdomains or some pattern in the URL whenever necessary with SPARQL FILTER patterns (or MINUS). More usage of sameAS and exact match (P2888) are really where we want to be at long-term for the health and maintenance of Wikidata to more easily support Linked Data and concept ontology mapping with the world. If your use case is not for semantic equivalency, then let's talk about that more to see if we can help with possible other existing properties. If you actually need help with SPARQL querying and filtering, etc. then let's move that discussion to the mailing list to get everyone involved that could help. --Thadguidry (talk) 19:20, 14 May 2021 (UTC)
• Thadguidry I think I'm starting to understand what you're saying, and if I am, doesn't it call into question most separate identifier properties that have been established? Which I think is what you are saying. Ultimately I just want to link from Wikidata to information about our buildings, so if 'exact match' is what will do that, that's great. Please have a look at Savery Hall (Q98534810), where I added exact match (P2888). You'll see we already had described at URL (P973) with the same URL, because the building is described there. Is it appropriate to have both statements in the item? UWashPrincipalCataloger (talk) 19:34, 14 May 2021 (UTC)
• UWashPrincipalCataloger Yes it does call into question many of the previous proposals that to my eyes were simply 'exact match' cases, but some have been legitimate 'Identifier' cases because of some project or national importance, etc. Is there a difference between the capitalized version 'SAV' and non-caps 'sav'? NOTE: Also, I'm not saying this proposal might not be useful, it depends on your needs or some project needs, if it's about semantic equivalency, then 'exact match' is your friend. If it's about storing identifiers in Wikidata to ease some programmatic queries or expressions or even some Wikibase extension that you guys might be working on, then certainly you'll probably want to have a new property to hold the identifier. Yes, you can have exact match (P2888) and described at URL (P973) on an item, where they give different relationships about an entity. For instance, you probably know best which property to use to add this URL [https://www.srgpartnership.com/work/savery-hall] Where Savery Hall is also an award winner, well, maybe correctly, it's the handiwork or subject of a few folks or orgs that won an award? ;-) --Thadguidry (talk) 19:56, 14 May 2021 (UTC)