Wikidata:Property proposal/URL for freedom of information requests

URL for freedom of information requests[edit]

Originally proposed at Wikidata:Property proposal/Organization

Done: freedom of information requests URL (P10214) (Talk and documentation)

Description	An URL pointing to a form or other page allowing citizens to make freedom of information request to public organizations
Data type	URL
Domain	government (Q7188) and public organizations of various types.
Example 1	National Aeronautics and Space Administration (Q23548) → https://socialforms.nasa.gov/foia (qualifier: object has role (P3831) → official (Q29509043))
Example 2	Defense Nuclear Facilities Safety Board (Q5251405) → https://www.foia.gov/request/agency-component/202a5719-0852-4b35-9ad9-dc9d2021d403/ (qualifier: object has role (P3831) → official (Q29509043))
Example 3	Katrineholm Municipality (Q508140) → https://handlingar.se/en/new/municipality_of_katrineholm (qualifier: object has role (P3831) → unofficial (Q29509080))
Example 4	Civil Aviation Authority of Uganda (Q5124427) → https://askyourgov.ug/body/caa (qualifier: object has role (P3831) → unofficial (Q29509080))
Planned use	Will be added through Wikidata:Gov Directory
Expected completeness	always incomplete (Q21873886)
See also	citizen's initiatives URL (P9732), WhatDoTheyKnow organisation ID (P8167), FragDenStaat public body ID (P6744)

Motivation[edit]

URLs for freedom of information requests could be very valuable to the general public. This is aimed at public organizations in jurisdictions enforcing freedom of information. As it's not uncommon that online freedom of information requests services are civic initiatives I propose that object has role (P3831) with an value of official (Q29509043)) or unofficial (Q29509080)) would be a mandatory qualifier. Abbe98 (talk) 07:47, 13 July 2021 (UTC)[reply]

Notified participants of WikiProject Govdirectory Abbe98 (talk) 16:03, 2 August 2021 (UTC)[reply]

Discussion[edit]

Support Ainali (talk) 08:28, 13 July 2021 (UTC)[reply]
Support NMaia (talk) 05:22, 14 July 2021 (UTC)[reply]
Support Salgo60 (talk) 13:17, 14 July 2021 (UTC) - (comment I guess Type item gives better design see below)[reply]
Support Popperipopp (talk) 09:45, 22 July 2021 (UTC)[reply]
Oppose While storing information for an URL for freedom of information requests is valuable, I see no reason why this should be it's own property. Why not URL (P2699) with some qualifier? ChristianKl ❪✉❫ 09:59, 20 July 2021 (UTC)[reply]
Using a new property for this type of URL follows the pattern of other Wikidata properties such as terms of service URL (P7014), charter URL (P6378), privacy policy URL (P7101), accessibility statement URL (P9494) and many others. Abbe98 (talk) 11:13, 20 July 2021 (UTC)[reply]

@ChristianKl: Is this a general oppose for all URL property proposals or do you have a specific reason that this one in particular should not be it's own property? Ainali (talk) 16:43, 20 July 2021 (UTC)[reply]
Yes. Given the situation of creating new properties in that fashion having a qualifier that easily allows people to properties like this seems to me like a better way. It means that if another user has a sixed type of URL for which they want to store in Wikidata they could just use the qualifier and don't need to go through the property proposal process.

Having each new proposal of this kind go through the property proposal process does allow us better to filter out potential undesirable urls to be stored, but I wouldn't expect that to create a huge problem. ChristianKl ❪✉❫ 08:49, 21 July 2021 (UTC)[reply]

An advantage of a separate property is that it would avoid the (recent) problems of P973 where some people may dump URLs without a clear scope nor any prospect of them ever becoming values for external-id properties.

An alternative could be to create a dedicated property for types of interactions with government organizations and add the url there, similar to front and back matter (P8570) describing default features of books. --- Jura 12:32, 21 July 2021 (UTC)[reply]

If you want to make it a general objection you should bring it up on project chat to get community support for all of these rather than oppose a random proposal. That way, if there is support, proposals like this does not even need to be started. Ainali (talk) 22:02, 21 July 2021 (UTC)[reply]

I do not disagree with your reasoning but if we use a dedicated property it will be easy to migrate if there is an agreement regarding a more general policy. Let's not block this but keep the general discussion going somewhere. Abbe98 (talk) 06:49, 22 July 2021 (UTC)[reply]

Using an available other property is a valid argument to object the creation of a new property. No real "change of policy" is needed. That being said, I don't think using URL (P2699) is a good idea, as it's a property without any scope beyond the datatype. --- Jura 10:37, 22 July 2021 (UTC)[reply]

The objection however was general and not specific to this property but to the pattern of many URL properties. I agree with your opinion on URL (P2699). Abbe98 (talk) 10:44, 22 July 2021 (UTC)[reply]

Still, to invalidate it, one would have to delete URL (P2699). I had a similar argument at Wikidata:Property_proposal/financials_URL (and some odd other). --- Jura 11:20, 22 July 2021 (UTC)[reply]

Actually, there is User:Lucas Werkmeister/P642 considered harmful that may be relevant to both. --- Jura 09:50, 23 July 2021 (UTC)[reply]

- "Using a new property for this type of URL follows the pattern" I like the idea of having more structured data in Wikidata but after playing with citizen's initiatives URL (P9732) (map what we have today) I feel we should have a design that is more advanced than an URL. When we get a datadriven society and can request things like this with something like a webservice this should be part of our description in Wikidata i.e. have a schema what information can be part of a request, languages supported, type of webservice, requested authorization, requirement like that you must be citizen in country zzz or live in xxx, main regulatory text (P92) why you can request, etc. - Salgo60 (talk) 18:56, 2 August 2021 (UTC)[reply]
  Agreed, but I think that system is qualifiers(as we summarized regarding citizen's initiatives URL (P9732)) the first step in that direction is for this property to have a mandatory object has role (P3831). We should collect these types of qualifiers and make sure we harmonize them across the various properties.
  
  citizen's initiatives URL (P9732) to me is so far a success very much thanks to your effort @Salgo60:, we should do more but must start somewhere. Abbe98 (talk) 20:04, 2 August 2021 (UTC)[reply]

Abbe98 With open data portal (P8402) we used datatype Item which I feel gives a better "denormalized design" than overload with qualifiers - see map.

Since before we hade an "URL property" external data available at URL (P1325) but I prefer not overload items with qualifiers....
lesson learned with citizen's initiatives URL (P9732) (map what we have with WD) as often when you start look into something you get surprised by the mess you find. With citizen's initiatives URL (P9732) I am starting learning that e.g. we in Sweden have 290 Municipals and we dont have one API instead we see nearly > 200 different implementations, name changes even if we have a law The Swedish Local Government Act (Q10547391) I guess they need to follow they create a mess... by having a separate item we can :
- "isolate" this mess in a dedicated WD item instead of a "denomalized" design and use qualifiers...
- in my humble opinion using item instead of URL is more future proof and cleaner...
- my feeling is that WD is not designed for having "all inclusive objects" i.e. the UI is slower when opening an object like Germany (Q183).... how is versioning done in WD is it optimized for "all inclusive objects"...
- ...

cc: Popperipopp Ainali - Salgo60 (talk) 05:24, 3 August 2021 (UTC)[reply]

I don't agree with the lessons learned. What you call a mess is just the normal state of the world. Expecting anything being in better order is unrealistic. That being said, I don't think items are the go-to solution. It just removes it one step and we're reaching higher number of items quicker and doing things harder to query for. Ainali (talk) 19:34, 3 August 2021 (UTC)[reply]

Ainali Its easier to query and you better support 1<->many eg. Dataportal Väst (Q100152716) as graph is the Open Portal for 22 WD items it makes no sense repeal this 22 times.... I guess you will have user cases like that for WhatDoTheyKnow (Q7990927) and many others. Looks like WhatDoTheyKnow organisation ID (P8167) "supports" 15 000 objects in WD (map)- Salgo60 (talk) 21:23, 3 August 2021 (UTC)[reply]

I'm not sure why you are discussing data portals here, this is not the page to change open data portal (P8402). Please take that discussion to that talk page.

Regarding to WhatDoTheyKnow (Q7990927), handlingar.se and the likes, I am very aware that they are a portal for many different agencies, but each agency will have statement with a separate URL, directly to their agency, something that would be lost if we only stored a link to an item about the website. (Please notice that this property is not meant to be used on an item of a portal website but on an item about an agency.) Ainali (talk) 13:03, 18 August 2021 (UTC)[reply]

I am not discussing dataportals it was just an example why its easier to have a "better" model than adding urls and qualifiers... I feel your way of design thinking/experience is another so good luck... - Salgo60 (talk) 22:13, 18 August 2021 (UTC)[reply]