Property talk:P7375

Documentation

• Start a query
• Current uses
• Statistics by class
• Network protocols
• List of qualifiers
• Count

MWNF URL
URL in the database of the Museum With No Frontiers (MWNF) virtual museum for the transmission of knowledge

Applicable "stated in" value	Museum with No Frontiers (Q17070255)
Data type	URL
Allowed values	^http:\/\/(carpets|sharinghistory|www|glass|islamicart|baroqueart)\.museumwnf\.org\/(#|database|thematicgallery).{1,200}$
Example	Church of St James, Toledo (Q2389665) → http://islamicart.museumwnf.org/database_item.php?id=monument;ISL;es;Mon01;29;en Al-Jawali Mosque (Q4702618) → http://islamicart.museumwnf.org/database_item.php?id=monument;isl;pa;mon01;13;en Reserve head Vienna KHM 7787 (Q2145603) → http://sharinghistory.museumwnf.org/database_item.php?id=object;AWE;at;28;en;N Goblet with Incised Designs (Q29385183) → http://www.museumwnf.org/thematicgallery/thg_galleries/database_item.php?id=glass&itemId=objects;EPM;us;Mus23;35;en
Source	http://www.museumwnf.org/database_results.php?cond2=AND&cond3=AND&keyword1=&keyword2=&keyword3=&field1=keyword&field2=keyword&field3=keyword&date_from=&date_to=&searchlanguage=
Related to country	Austria (Q40) (See 81 others)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Database reports/Constraint violations/P7375 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 12 Main statement 8 out of 6,240 (0% complete) 66.7% of uses Qualifier 4 33.3% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Format “http://(carpets|sharinghistory|www|glass|islamicart|baroqueart)\.museumwnf\.org/(#|database|thematicgallery).{1,200}”: value must be formatted using this pattern (PCRE syntax). (Help)

List of violations of this constraint: Database reports/Constraint violations/P7375#Format, hourly updated report, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7375#Entity types

Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)

List of violations of this constraint: Database reports/Constraint violations/P7375#Scope, hourly updated report, SPARQL

Why URL?

@ديفيد عادل وهبة خليل 2, Dominikmatus, Trade, Eihel, Pintoch: can any of you explain to me why you supported this property as being no external ID property? ChristianKl ❪✉❫ 08:17, 8 October 2019 (UTC)

• @ChristianKl: I did not support it - I only created it based on the existing consensus. − Pintoch (talk) 09:16, 8 October 2019 (UTC)

  @Pintoch: I think we have the property creator flag based on the assumption that there are people commenting on property proposals that don't know things like the difference between URL and external ID's. Doing a check about whether the proposal makes sense or whether there are open issues seems to me an integral part of the task of creating new properties. Do you think that responsibility shouldn't be with the person who creates the property? ChristianKl ❪✉❫ 11:59, 8 October 2019 (UTC)

  @ChristianKl: I reply yes, 100%. But I developed this proposal (and for someone else besides) knowing the difference between ID and URL (see also my reply below, please). I consider myself, in all modesty, a very correct level for my status. I even help an admin to do his RegEx and I reread the multitude of proposals several times a week by proposing corrections (because I do not impinge on a proposal). Some of these corrections are accepted, but others are not (recalcitrant to the understanding). I often want to vote against some skeletal proposals or proposals with aberrations. But, I hold back and I keep the reason and I propose to do the same before making accusations. You have the opportunity to file an application to this effect. There are certainly other things to change in the problematic that you are advancing: the proposers and voters are not all enlightened like you, even in the admin (I do not target anyone), so there are proposals that "pass the course" by becoming Properties. It is characteristic of a heterogeneous community. @Pintoch: created on his Git a tool to create properties and nobody thought of generalizing that. Once I looked at the list of creators, there was only one third who regularly made new properties. When applying for PC status, I do not talk about it. That said, I congratulate you for all the properties you have created. —Eihel (talk) 14:31, 8 October 2019 (UTC)

  @ChristianKl: yes, I typically check for datatype issues. In this case, because of the structure of the URL, it was not straightforward to convert it to an external-id. You could work something out with ArthurPSmith's proxy, but it is not clear that this is really desirable, since it would mean making up an id format that is not actually used anywhere else in the wild. You could also create multiple external-id properties for each subdomain, but it is not clear that it would be really better… Doing a check about whether the proposal makes sense or whether there are open issues seems to me an integral part of the task of creating new properties. Do you think that responsibility shouldn't be with the person who creates the property? yes absolutely, and so in this case I do believe the proposal made sense. In this case Eihel was clearly aware of the alternatives, they proposed a URL datatype knowingly (so the creation as URL is not a mistake). Because I suspected there would be people opposing this like you do now, I did not create the property 7 days after proposal and left a longer discussion period for it. So really, in this particular example I do not think I messed up… If you have strong feelings about external-id versus URL, this should have let you ample time to oppose the property in that state. As a property creator I try to create all properties for which there is a consensus, assuming there is no technical issue (such as inconsistent datatype), regardless of whether I personally like them or not. You can always nominate the property for deletion if you missed the discussion period. However if you want to bring up broader issues about my activity around property proposals, I would be happy to discuss that (perhaps on my talk page rather than here?) − Pintoch (talk) 09:05, 9 October 2019 (UTC)

  @ChristianKl: just checking if you still have concerns about how this property was created? − Pintoch (talk) 13:27, 11 October 2019 (UTC)

• I just tried having a look at one of the example in the proposal, http://glass.museumwnf.org/#/database-item/DGA/tr/Mus42/6/en − it does not resolve anymore and redirects to the home page. The correct URL is now http://glass.museumwnf.org/database-item/DGA/tr/Mus42/6/en.

Digging more into the glass URLs, one of the first items I encounted is http://glass.museumwnf.org/database-item/EPM/dn/Mus21/12/en, which actually recommends to link to http://islamicart.museumwnf.org/database_item.php?id=object;EPM;dn;Mus21;12;en ; so it looks like that these URLs are not really stable, and that that the various websites, while not interchangeable, are at least to a certain degree frontends for the same underlying data.

The proposal stated that “the catalog entry types are numerous”, but the examples given are only “object” and “monument” − so wouldn’t a “Object ID” and “Monument ID” be better? Jean-Fred (talk) 10:50, 8 October 2019 (UTC)

• As mentioned in the proposal discussion, this property does not contain a constraint of type (catalog variety), but especially catalog entries can be found in several places in WD (some general objects). In addition, entries in this catalog are in other collections (virtual museum). The complexity of the URL means that the primary statement and the only remaining one is the URL contained in the RegEx (format constraint) and this property no longer looks like an usual identifier. So I chose URL for this property. As described in the type explanation, a URL type can serve as an identifier. That said, if your wish is that it is in the part Identifiers, that also agrees to me.

  If I am not against @ChristianKl:, I  Strong oppose the opinion of @Jean-Frédéric:.

  So you found 2 of my entries in the catalog: object and building. Congratulations. So we agree on these 2 instances or subclass. To which I add those I found:

  • Hafiz Ibrahim (Q2993475) → [1], so instance of human (Q5)
  • Temple Mount (Q193163) → [2], so instance of physical location (Q17334923) (as debate)
  • There are even physical location (Q17334923) without construction: [3], so physical location (Q17334923).

  In addition, following future MWNF partnerships, other instances may arise. As no one from WD scans each catalog, we have to plan wide.

  For http://glass.museumwnf.org/#/database-item/DGA/tr/Mus42/6/en, I added the URL from the catalog search page, but the correct URL is without the #, that is, http://glass.museumwnf.org/database-item/DGA/tr/Mus42/6/en. This is a bug on the site on themes (glass, for example), but the URLs are constant. In addition, depending on the operation of the museum (virtual exhibitions), other instances can be added. The RegEx being the "dam" to the misuse of the property. For all, I did my best to make a correct proposal.

  @Pintoch: "Major changes to a property should be discussed on its talk page first", and a datatype can be changed by a sysadmin: "To propose such a change, you may start a discussion at the talk page of the property or project chat. After a consensus, a request may be made in Wikidata:Contact the development team". We may be against the proposal, but not against proposing: the properties are not engraved in the stone.

  Phew! I replied everyone. Cordially. —Eihel (talk) 13:00, 8 October 2019 (UTC)

  Thanks for the reply, and while I apologise if my question came across the wrong way, your “Congratulations” come across as snarky which I find a bit unwarranted to be honest.

  My point was not so much about what instance of (P31) the items should be ; but that (and granted, I could have been clearer) the URLs seem to either be database_item.php?id=monument; or database_item.php?id=object; (including the two example you give above), hence my thought that these could map to two separate identifiers − I may well be wrong of course, as I have not done extensive research in this identifier. :-) Jean-Fred (talk) 20:14, 8 October 2019 (UTC)

  Hello @Jean-Frédéric:,
  URLs also start differently: there are different collections. Following museum.org/ too, your URL portion may be thematicgallery instead of database_item, as in this link. database_item is further in the URL. You also find monument and object, on this link you also have GALLERIES. So it's not just your 2 solutions: everything is in the RegEx (hence the URL datatype). But the identifiers of museums and GLAM in general do not need a Property for each collection. With my respectful greetings. —Eihel (talk) 17:10, 17 October 2019 (UTC)

• What about asking the webmasters of that database if they could add unique ID to every object so it could be linked? Dominikmatus (talk) 19:52, 8 October 2019 (UTC)