Template talk:Geograph from structured data

This template gives errors in the description, as it doesn't work correct with coordinates. See this discussion. Grüße vom Sänger ♫ ^(talk) 16:49, 8 March 2020 (UTC)

Rome wasn't built in a day, give it some time. I fixed the tracking categories being added incorrectly. Still have to look into the {{Object location}}. Multichill (talk) 19:40, 8 March 2020 (UTC)

experimenting with new look

@Multichill: I am experimenting with a new look where links to SDC are added by a little pen icon after a value. I borrowed the approach from Module:WikidataIB. --Jarekt (talk) 05:26, 26 March 2020 (UTC)

@Jarekt: I like it! Multichill (talk) 17:15, 26 March 2020 (UTC)

Template:Information/sandbox

@Jarekt: I noticed you switched the main template, but that leaves us with several other cases where we still use the sandbox version. Was this intentional or not? Can we switch those to the main template too or is it not ready yet? Multichill (talk) 16:38, 25 April 2020 (UTC)

Oh, yes. I replaced them too. --Jarekt (talk) 01:17, 27 April 2020 (UTC)

@Jarekt: thanks, the template starts to look really nice! Multichill (talk) 12:16, 2 May 2020 (UTC)

location

User:Nilfanion, You modified this template removing "location" field as confusing. Can you explain what is confusing about providing location? If you find format confusing we can try to modify it, if you have a better suggestion. --Jarekt (talk) 15:37, 4 May 2020 (UTC)

Restored it. Just removing functional parts of templates is not cool. Multichill (talk) 16:05, 4 May 2020 (UTC)

There are two issues which lead to confusion:

• The location provided by this template is the wrong one. The file description page should describe the location depicted (derived from P180 or whatever). I'm not sure if it is possible to break a location out of various P180 parameters but that is by far the most important location.
• Furthermore the file page will always have "object location" and "camera location" fields. A better title for this field is needed to give clarity as to what this location actually is.

IMO the coordinates provided the camera location field are much better at conveying where the photo was taken from than a placename. The camera is always at a single point, and the coordinates express this more clearly than the placename.--Nilfanion (talk) 17:07, 4 May 2020 (UTC)

I am OK with using different name than "Location". I think that is unfortunate that on Commons we use term "location" when we mean geographical coordinates. That lead to a lot of confusion. Template:Information2 used term "Location" for many years to provide field to location related wikitext, so there is a long history of using that label. I suspect that in majority of cases depicted location and location based on coordinates should be the same, so maybe we can have some manual special treatment for the cases when they are different. Nilfanion how many files you found where they are different? As for extracting locations from depict statements, that seems like not a very liable source since many file might be missing depict statements with locations. --Jarekt (talk) 19:10, 4 May 2020 (UTC)

For this specific template, it would be viable to extract a location from the depict statements. That's because because all the source files on Geograph have subject coordinates and the bot can use these on upload.

My concern is this template is using location of creation (P1071) as a proxy for the subject's location. Semantically we should only use location of creation (P1071) to encode the position of the camera. That needs to be kept distinct from the location as future improvements could lead to incorrect output. The bot is only using broad areas, but what if someone decided to instead use it to say what street the subject is on?

To take an extreme example: The bot would apply "Exeter" to File:Exeter cathedral (16968019508).jpg. However it could easily have a depicts (P180) "Exeter Cathedral organ" and location of creation (P1071) "West end of nave". That P1071 statement is useful and valid, but is not the location of the organ.

This is a concrete example of the problem with the Geograph files. It will take me some time to parse a more complete list. Please consider the principle of getting things right, not the number of affected files.--Nilfanion (talk) 20:11, 4 May 2020 (UTC)

There are a lot of issues we can improve on this project, so before investing a lot of volunteer time to fix a potential issue following principle of getting things right I would rather check if this is actually a problem affecting many files. If there are only few files affected by depicted location being different than camera location than we can do some extra good manual tagging for them. I think a consistent field with jurisdiction level camera location would be great, but it would be nice if there was a way to add manual description to the image in case anybody knows more about the image than what we get from the source. --Jarekt (talk) 03:38, 5 May 2020 (UTC)

I think I have generated a ton of noise here, as the fix is trivial: Make it clear that this location is the camera location, and always provide the subject location as well. ALL Geograph files can have this and it can be placed in the depicts. Do NOT use field for camera location as a proxy for the subject location as well, but always add both, even if identical. All that is needed for that is a minimal change to the bot coding.

In order to improve things slightly, I have moved the field to the end of the {{Information}} template. It is logical to place both things that relate to the camera location together, and this looks better. I have also changed the call from {{I18n/location}} to {{I18n/location|made}}, as this clarifies what this location is. I would have preferred to use {{I18n/location|camera}}, but that would result in duplication.--Nilfanion (talk) 07:35, 5 May 2020 (UTC)

The "location made" was the field I was looking for. Didn't know we had that in the i18n library already. I like the grouping at the bottom, makes the template more logical.

Just to make sure: location of creation (P1071) is about where the work (the photograph in this case) was made, not what you see in the work. So it's never about the object/subject, for that we have depicts (P180). See this remark for that. Multichill (talk) 10:22, 5 May 2020 (UTC)

I'm happy with how P1071 is now being used, but that property is purely metadata. The subject location is also metadata, but it is also valuable for primary description of the image.--Nilfanion (talk) 08:13, 7 May 2020 (UTC)

Improvements

There's a few things I can see to improve things further:

1. Change the Depicts to have links instead of being raw text (so it will display House instead of house, or Woodbury instead of Woodbury). This clarifies what each entry is.
2. Have a field for the subject location, which can then invoke PropertyChain.
3. Move the location of creation (P1071) call within {{Location}} itself. That means the placenames will be contained within the same field as the coordinates. This would affect all files with a {{Location}}, and while this is beneficial to all, is a very different task.--Nilfanion (talk) 07:57, 5 May 2020 (UTC)

Description

This section is completely broken in its current form. While it makes sense to call the file's caption, as this gives consistent output, it also causes a swathe of problems:

1. Users can disable captions via Gadgets. If they do so they cannot edit the description, no matter how hard they try, and there is no indication that they need access to the caption.
2. If captions are not disabled, while the user can edit the description, it is not clear how they do so. With all the other fields, clicking the edit pencil takes them to the structured data and moves the focus to the correct field. This is intuitive. Clicking the pencil in the description doesn't move you to a separate page but adjusts focus on the same page. This is not clearly telling the user "you need to edit the caption to edit the description".
3. As the description is providing the exact same information as the caption, there is duplication. IMO, the template presents that info in a much tidier way than the caption.

I can think of two solutions to this:

1. Change the template to have a traditional description field. Users can then edit it as normal.
2. Display the caption on the structured data tab. This is in addition to the regular display on the file information tab. If a user tries to edit the description, it can then behave like the rest of the structured data: Switch tabs and highlight the relevant section. This is intuitive, and needs checking to ensure if the user has captions disabled via gadgets they can still access.

In addition, it would be good to hide the caption on the file information tab for all users to remove the redundancy and present things more neatly.--Nilfanion (talk) 08:28, 5 May 2020 (UTC)

If a user is capable of disabling the captions with a Gadget than it became the problem of the user. The user deliberately broke it. Not going to try to fix that.

I think I mentioned this something else before, but in the long run I think we should have:

• Current tab "file information" should be the display tab where you can easily see all the information about a file in the format relevant to the type of work.
• Current tab "structured data" should be the edit tab where you can easily edit the information about a file (including the captions). Probably should have a raw mode (what we have now) and a domain mode where you get a form relevant to the domain which you can fill out to fill the holes

This is longer term stuff and that's not going to happen anytime soon. Multichill (talk) 09:59, 5 May 2020 (UTC)

I agree with the long-term goals there.

In the short-term, we need to make it apparent how to edit, and that could be done by slight tweaks to the template. Changing this () to ( Edit the caption) would address this. That explicitly tells the user what to do, so they know what to do next. A user has disabled captions via a gadget will now have a chance realising the gadget is his problem.

I would recommend removing the majority of the icons. Only retain those that actually should be edited (ie the Description and Depicts). In 99.99% of cases the other fields will stay untouched. This also helps guide the user to how to actually edit things.--Nilfanion (talk) 10:43, 5 May 2020 (UTC)

Add other_versions?

Unlike {{Information}}, this template doesn't take an other_versions parameter, which means that there isn't a way to link to other versions of a picture. This would be a useful addition, but I haven't yet tried to work out how to do it. --bjh21 (talk) 21:26, 2 June 2021 (UTC)

@Bjh21: I would like to use related image (P6802) for that in the structured data. In the future cualifiers could be used for the type of relation (the source, a crop, etc.).

Would be a nice addition to {{Information}} and {{Artwork}}. We could pilot it with this template and later move it to the generic templates. @Jarekt: do you think you can help with this? Multichill (talk) 19:01, 4 June 2021 (UTC)

@Bjh21: I added other_versions template parameter. --Jarekt (talk) 20:18, 4 June 2021 (UTC)

That would have been the quick and dirty fix. I removed it again because currently the template is free of wikitext template parameters and I would really like to keep it that way. Feels like a relapse to add it. Multichill (talk) 20:38, 4 June 2021 (UTC)

@Multichill: related image (P6802) seems to be concepts which do not have image (P18) but do have some image related to the topic. The purpose of this Wikidata property seem to be quite different than what you are proposing to use it for on Commons. I am worried that there might be some constraints added in the future that make sense for original use but break the alternative use. --Jarekt (talk) 20:27, 4 June 2021 (UTC)

@Jarekt: I noticed that too. Looking at the property proposal this predates structured data on Commons and it was done to make a clear difference between the new property and image (P18). I put a message at d:Property talk:P6802 linking it to Commons_talk:Structured_data/Modeling#Related_images. Multichill (talk) 20:38, 4 June 2021 (UTC)

Titles that start and end with apostrophes mishandled

It seems that when the title of a picture starts and ends with an apostrophe, the title as shown in the licence template lacks those characters and ends up in upright rather than oblique type. See File:'Here comes Richard' - geograph.org.uk - 2379309.jpg, compared with File:Richard and 'Archimedes' - geograph.org.uk - 2379215.jpg as an example. The problem seems to be that the '' marks in the template to put the title into oblique text get merged with the apostrophes in the title to form ''', signalling bold text. One way to fix this would be to use <i> and </i> in place of ''. Another would be to wrap the title in <nowiki> and </nowiki>. --bjh21 (talk) 16:45, 21 August 2021 (UTC)

How to edit the structured data this template uses

I'm afraid this template has completely defeated me, despite being a long-time Wikipedia, Commons, Wikidata and Geograph project user. I cannot work out how to find, let alone edit, the structured data it purports to be displaying. The most obvious way, by clicking the pencil icons next to the values, seems to do absolutely nothing except for the one next to Depicts (it was actually Date I wanted to edit). Selecting the Structure Data tab seems to show that the only piece of Structured Data the image has is Depicts, which kind of explains why the pencil doesn't work on Date. So where is the template getting all the other information it outputs, and how do I edit it. Obviously I can remove the template in its entirety, and replace it with the 'Wikipedia Template for image page' that Geograph helpfully gives me, and I must confess I have been doing this until I realised how widespread this template was. There surely must be a better way. -- Chris j wood (talk) 12:22, 16 May 2022 (UTC)

If it helps to have an example of the page I was trying to edit, here is one: File:Thames cable car - geograph.org.uk - 3205431.jpg. -- Chris j wood (talk) 12:26, 16 May 2022 (UTC)

Well that is seriously weird. I've spent days scratching my head trying to work out what I was doing wrong. Eventually decided it could not be me, so posted above. Now a couple of hours later I've tried again and suddenly there is a whole load of extra structured data there, and the pencil works fine. A sly fix on the QT, or something environmental (I have rebooted my PC, for entirely unrelated reasons, in the meantime?. -- Chris j wood (talk) 14:51, 16 May 2022 (UTC)

Request to use, or simulate, Template:Taken on in displaying date

So I'm now able to edit dates (see previous topic) but that doesn't help. The reason I was trying to edit the date was to include the 'Taken on' text that is conventionally added to dates on Common's images by the Taken on template. But the editor insists on an undecorated date (I guess that is what structured means).

The reason we include this text is because, for better or for worse, our knowledge of dates for Commons images is incomplete. Sometimes 'Taken on' needs to be replaced by 'According to EXIF data' or even 'Uploaded on'. Just presenting a plain date, without any clue to what it is the date of, is ambiguous. That is, of course, not to say that there aren't a awful lot of images that are ambiguous in this way, but I'd prefer not to add a further 1.6m images to that list (current transclusion count for this template). At least with images from Geograph we do know the taken date to some degree of accuracy, even if it is only to the year, but that is not the general case with all Commons images. So I'd suggest that this template uses (or simulates) the Taken on template in displaying the data.

There are a couple of complexities here. The Taken on template takes a location parameter, conventionally but not always set to the country, which it uses to add the image to a "<location> photographs taken on <date>" category, and if that is not present and 'cat=no' is not passed, instead puts them in a "Photographs taken on <date>" category. I'd suggest using the 'cat=no' option, as that is already widely used, and leaves the decision on categorisation to editors in the normal way.

The other complexity is if only month-and-year or year are know, then the text is subtly different Taken in rather than Taken on and the template used is Taken in. But the principal is the same. -- Chris j wood (talk) 15:24, 16 May 2022 (UTC)

Derivative works; and user advice

Given that this template is quite the pathfinder for representing metadata almost entirely in SDC rather than wikitext, something many (most?) editors, and also many tools will not yet be familiar with or adapted to, I wonder if the documentation pages here might be a useful place to give users advice on how to do various standard things.

For example, I recently used Commons:CropTool to create this crop from this geograph image. CropTool isn't aware of SDC, so it created a new description page that had just the {{Geograph from structured data}} template, but with none of the SDC copied over to fill it. I have left a message on the CropTool talk page, but as the developer is away (and seems to have a raft of issues already to deal with), the functionality of the tool probably won't be evolving any time soon.

So a note here might be quite helpful, eg to explain what should be changed for best practice for a derivative work (? adding based on (P144), but retaining much of the information unchanged ?) and eg what good tools may exist for copying some or all SDC statements from one file to another (eg anything similar to the "moveClaim" gadget on wikidata).

I think such information here might be quite useful to people unfamiliar with SDC (and even to some with a bit more familiarity!) Thanks, Jheald (talk) 10:24, 17 July 2022 (UTC)

... except of course based on (P144) can only be used with a Q-item value, not a file value (nor an M-item value), . So I'm not sure how to indicate that a file is a derivative of another file. Jheald (talk) 10:27, 18 July 2022 (UTC)

Category sort order?

Can anyone explain this? Is it related to this template?

Category:Stone arch bridges in Cumbria is a photo gallery of bridges, mostly sourced from Geograph. Some use the old {{Information}} and {{Geograph}} templates, some use the {{Geograph from structured data}}. The sort order on them has "split in two", such that there's an A..Z series, then a second A..Z series.

Wrynose Bridge ... (with {{Geograph from structured data}}) is sorted before Above Hincaster Tunnel ... (with {{Geograph}}) Is one of these sort orders getting prefixed with something? Andy Dingley (talk) 17:57, 14 January 2023 (UTC)

@Andy Dingley: {{Check categories-Geograph}} is adding a defaultsort. Not sure how useful that template still is, I was thinking about getting it deleted. Multichill (talk) 12:10, 15 January 2023 (UTC)

Ah, that makes sense. And it's the template I'd not checked, because I hadn't expected such a behaviour. Also the Z prefix (pushing down, rather than up) was unexpected. Andy Dingley (talk) 12:15, 15 January 2023 (UTC)