Property talk:P10271

From Wikidata
Jump to navigation Jump to search

Documentation

Engineer's Line Reference
code for a railway line in Britain owned by Network Rail
Associated itemNetwork Rail (Q1501071)
Applicable "stated in" valueEngineer's Line References (ELRs): A (Hopefully) Comprehensive Listing (Q110591790)
Data typeExternal identifier
DomainELR railway line section (Q113990375)
Allowed values[A-Z]{3}[0-9]?
ExampleAshford to Ramsgate Line (Q4805019) → ACR
Catford Loop Line (Q5051993) → CAT
Reading Line, Waterloo to Wokingham Junction (Q110591071) → RDG1
Reading Line, Wokingham Junction to Reading (Q110591295) → RDG2
SourceEngineer's Line References (ELRs): A (Hopefully) Comprehensive Listing
Related to country United Kingdom (Q145) (See 326 others) (United Kingdom (Q145))
Lists
Proposal discussionProposal discussion
Current uses
Total16,948
Main statement3,335 out of 1,595 (209% complete)19.7% of uses
Qualifier13,61380.3% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Single best value: this property generally contains a single value. If there are several, one would have preferred rank (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/P10271#single best value, SPARQL
Distinct values: this property likely contains a value that is different from all other items. (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/P10271#Unique value, SPARQL (every item), SPARQL (by value)
Format “[A-Z]{3}[ZX\d]?: value must be formatted using this pattern (PCRE syntax). (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/P10271#Format, SPARQL
Type “ELR railway line section (Q113990375): item must contain property “instance of (P31)” with classes “ELR railway line section (Q113990375)” or their subclasses (defined using subclass of (P279)). (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/P10271#Type Q113990375, SPARQL
Qualifiers “linear reference (P6710), subject named as (P1810), identifier shared with (P4070), reason for preferred rank (P7452): this property should be used only with the listed qualifiers. (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/P10271#allowed qualifiers, 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/P10271#Entity types
Scope is as main value (Q54828448), as reference (Q54828450), as qualifier (Q54828449): the property must be used by specified way only (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/P10271#Scope, SPARQL

Queries[edit]

map[edit]

progress[edit]

section matching[edit]

data[edit]

maintenance[edit]

checks[edit]

more[edit]

  • https://w.wiki/5kaY number of sections with 0 / 1 / 2 / 3 terminus locations (as indicated by their having different mileages).
  • https://w.wiki/5kne Sections with 2 items, in non-adjacent counties
  • https://w.wiki/5koj Sections with a single item, in a different county to any items on adjacent sections
  • tinyurl.com/2mrwebuk -- unlocated terminus/terminus junctions with nearest located point on each line
  • tinyurl.com/ux2ep2z7 Comparison of RailScot, NetworkRail, RailwayCodes, and Canmore/NHLE/Cadw names for bridges with a NR id

Errors and anomalies at the RailwayCodes site[edit]

codes of stations in stations list[edit]

links to sections from stations list[edit]

locations (topological changes)[edit]

mileages[edit]

more[edit]

names[edit]

viaducts[edit]

wrong line[edit]

possible wrong section (or redefined sections)[edit]

incorrect junction cross-references[edit]

Corresponding track sections[edit]

@PhiH, Lnkvt: Hi! Thanks for getting this property created, and starting to make items for the corresponding track sections.

I'm thinking of using the information in the tables at eg: http://www.railwaycodes.org.uk/stations/stationa.shtm and http://www.railwaycodes.org.uk/viaducts/viaducts1.shtm to start adding mileage information to items for stations and bridges, using the property linear reference (P6710).

Now P6710 is most commonly used as a qualifier on the connecting line (P81) property (query). But we already have rather a lot of different kinds of railway line (Q728937) that can provide values for connecting line (P81). For example, here's a query https://w.wiki/5hm8 for the different lines that are values of connecting line (P81) for items in Scotland. Already it's being used for a mixture of items for long-distance lines (probably the value that templates on wikipedias most seek), historic/original lines, possibly current marketing names (cf [10]), potentially LOR/PRIDE sections (cf [11]) ...

It's my feeling that, for readability and to reduce clutter, it would be useful to keep ELR sections as a distinct thing in their own right, and therefore as far as possible treat them distinctly from other more generic cases of railway line (Q728937) -- and in particular to try not to use connecting line (P81) in connection with statements specifically relating to ELR sections if there might also be P81 statements relating to other railway line (Q728937) roles.

Luckily we have a bit of redundancy in our properties, so I'd like to propose that instead we might instead use located on linear feature (P795) on station items etc in this case to give statements such as

Stirling railway station (Q975320)located on linear feature (P795)Scottish Central Main Line (Dundee to Motherwell via Stirling), Whifflet North Junction to Dunblane (Q113645961)
Engineer's Line Reference (P10271)SCM3
linear reference (P6710)118.3 miles

with reference

stated in (P248)Engineer's Line References (ELRs): A (Hopefully) Comprehensive Listing (Q110591790)
reference URL (P854)http://www.railwaycodes.org.uk/stations/stations.shtm#stg
object stated in reference as (P5997)118m 24ch

(The last bit is necessary I think, because I don't believe wikidata numbers can handle non-decimal fractions yet!)

Bridges would use the same form but with two linear reference (P6710) qualifiers (on the same statement).

I'd suggest we also use the same form to indicate what ELR sections a railway line is made up of, rather than has part(s) (P527). (We might also like to indicate whether the line includes the whole of the ELR section or only a part; but I'm not sure how to do that, perhaps object has role (P3831) = "partially included", or similar).

One thing I suggest we do not do is apply Engineer's Line Reference (P10271) as a main-value property to things other than ELR sections -- eg the current use of RDG1 on Waterloo–Reading Line (Q6265162) (link) as well as Reading Line, Waterloo to Wokingham Junction (Q110591071). Doing so means that a query can no longer easily identify the precise item that a code refers to; and the standard search like [12] no longer returns only a single item. I'd therefore suggest that a particular ELR code should only apply to a single item. I'd also suggest that it would be useful to create a specific class, that such items must belong to "ELR section of railway line", rather than just the generic railway line (Q728937).

Do people think these suggestions would make sense? Cc'ing also @Tagishsimon:, who's done quite a lot on infrastructure in Scotland, eg creating items for junctions and bridges. Jheald (talk) 14:16, 14 September 2022 (UTC)[reply]

I agree with your suggestion to have items for all ELR lines. If we implement that concept, these items should be the only items where Engineer's Line Reference (P10271) is used. --PhiH (talk) 18:10, 14 September 2022 (UTC)[reply]
This all seems reasonable. Summarising, we have a full set of ELR items, use them as located on linear feature (P795) statements on other line, bridge & station items; and use non-ELR lines for connecting line (P81) values; reserve ELR codes for ELR items. And use "ELR section of railway line", rather than railway line (Q728937).
Q. Ditto for branch line (Q655677) & what about chord (Q691244) for ELR items? https://w.wiki/5he3 --Tagishsimon (talk) 19:05, 14 September 2022 (UTC)[reply]
Yes. One of the things I think User:Lnkvt has been quite carefully trying to do is to match ELR codes to existing items. Here's a query https://w.wiki/5hee for items with Q-numbers less than 110 million (the current Q-number when the property was introduced), that have ELR codes. Many ELR sections, such as Scottish Central Main Line (Dundee to Motherwell via Stirling), Whifflet North Junction to Dunblane (Q113645961) above, I think are not the first values one would choose to give {{P|250for connecting line (P81) values for stations, or carries (P2505) values for bridges. But there are other ELR sections, in particular the ones User:Lnkvt has matched to existing items, that likely do exactly correspond with the line identifications one would want to see on a Wikipedia template. This may be especially true for branch lines, where likely the whole branch exactly corresponds to the section of line identified by the ELR code. In such cases I think it makes perfect sense for such an item to carry both instance of (P31) = branch line (Q655677) or chord (Q691244) or whatever, as well as a P31 = "ELR section of railway line", and it would make sense for them to be the connecting line (P81) for stations, as well as (wearing their ELR section hat) the value for located on linear feature (P795) statements with ELR identifiers and mileages.
(Though maybe we should more systematically start to separate items for lines from items for companies that initiated them).
So far User:Lnkvt has been moving quite steadily, checking to see whether an item for a line already exists before creating a new ELR section item. That's very much how I usually tend to work too, doing all I can to match external IDs first, and only as a last resort creating new items. But here (if User:Lnkvt is okay for me to do it), I think the alternative would make sense: to create items for all remaining ELR sections first, then try to match them and/or identify which lines use them, that we have existing items for. In particular I think having the sections and their station-relationships in wikidata will open up the possibility of using queries to identify which pre-existing items may be related to ELR sections through the stations that are identified to them. And then one could look for which non-ELR line items cannot be traced successfully and continuously from end-to-end via the ELR items they have been linked to. Both of these I think would make for quite powerful tools for helping to relate existing lines to sections (if User:Lnkvt you would be happy for me to go ahead and do that. And @Tagishsimon: I hope you feel that would be a satisfactory approach re your Q ? Jheald (talk) 23:11, 14 September 2022 (UTC)[reply]
I am not against creating a new line type ELR section but I am not sure what is gained by that. The concept of a railway line is not very well defined. What is a single line by one definition may be multiple by another. Things become more complicated when viewed from a historical perspective, like for instance Q792406 which was a single line with continuous mileage in Yugoslavia but is now split across multiple countries each with its own identifiers for the sections on its territory (Q101577359, Q111981886). In short: for me any part of a railway line is okay to be considered itself an instance of railway line as long as there is a property that is unique to that part, especially if that property is an identifier.
My activity on the railway data is a side-effect of a multi-year hobby project where I map all the railways in Europe and relate them to open data. Wikidata is a natural provider for country-independent identifiers for that. As I work from lists of lines, junctions and stations for each country, I try to relate them with existing wikidata items to establish links to Wikipedia articles as sources. This is why I link to existing items in principle and only create new items if I cannot find them, but as I am basing my map on technical lists such as ELRs in the UK and STREDA line numbers in Germany, there are a lot of new items to add.
In the case of Great Britain, I think ELRs should only be assigned to (subclasses of) railway line. Now, there are many cases where the concept of a railway as a company and a line as infrastructure is combined in one Wikipedia article. In such cases I have chosen to simply add 'instance of railway line' before adding the ELR data. Splitting these into separate 'company' and 'infrastructure' items with roughly the same name might be ontologically correct but adds little practical use and would perhaps lead to other editors merging them again. Also, it sort of defeats my intent to use the Wikidata identifier as a linking mechanism to articles on Wikipedia. Lnkvt (talk) 21:49, 15 September 2022 (UTC)[reply]
I have gone ahead starting to create new items for the remaining ELR sections. These can be identified as having Q-numbers starting with Allington West Junction to Barkeston East Junction (Q113991317) and above. Many may subsequently get merged, once it becomes clearer what relates to them.
I have also gone ahead and created an class ELR railway line section (Q113990375) for the items to be instance of (P31), which can be useful for extracting them as a group, and is useful to indicate that these are sections of track that have extents defined by the ELR reference. But the class is a subclass of railway line (Q728937) so it shouldn't break anything (and I haven't removed any of the old P31 statements). I have also added a distinct-values constraint (Q21502410), so only one item should hold any ELR reference; and also removed applies to part (P518) as an allowed qualifier -- if an item has an ELR value, it should represent all of it.
I will hold fire for the moment on splitting 'company' and 'infrastructure' items. I agree it's good to try to keep links together. One issue is different dates for dissolved, abolished or demolished date (P576) for when the company was amalgamated (often soon after laying the line) vs when the track was torn up. If we were to split out companies, we could maybe leave the item for the track section holding both the Commons link and any wikipedia sitelinks. Jheald (talk) 23:04, 15 September 2022 (UTC)[reply]
Another thing to consider is using the 'parent' ELR, for items such as RDG1 Q110591295, RDG2 Q110591071 which are the two sections of RDG (see http://www.railwaycodes.org.uk/elrs/_mileages/r/rdg1.shtm). I would assign this ELR to the parent line, so in this case Q6265162 but I haven't started on those yet. Lnkvt (talk) 06:02, 16 September 2022 (UTC)[reply]
My first instinct is that's not a good idea. The single-value and distinct-value constraints are very valuable checks. I'd rather know we had items that were a 1:1 match with ELRs. (Although in cases like INL / INN / Ingleton Branch Line (Q6032666) a merge would indeed be very tempting).
One thing I have noticed is that on eg Kyle of Lochalsh Line (Q586470) the ELR section starts where the branch leaves the Far North Line outside Dingwall. But the item currently has terminus (P559) = Inverness railway station (Q800959), which is where all the services actually start or go to. If we want to make the item correspond to the ELR (and also its history as a unit that was built etc), we should have terminus (P559) = Wick Line (Q113609853) / location (P276) terminus location (P609) = 'Dingwall Junction'. (EDIT: actually location (P276) does seem to be the more common qualifier). But how then to represent that services start at Inverness? The Kyle line with its services to Inverness way outside the ELR section is quite a dramatic example, but this is is actually quite a general issue for branch lines, even where they run to a junction station, because the junction station will typically be on the main line, outside the ELR section for the branch, which typically starts only where the lines diverge.
So how to represent where the services start and finish? Looking at qualifiers currently used on terminus (P559), https://w.wiki/5hwE , there doesn't seem to be any obvious candidate. On the other hand adjacent station (P197) might do to indicate the station nearest on from the junction; while scheduled service destination (P521) or towards (P5051) might do to indicate where services most commonly end up. Jheald (talk) 07:05, 16 September 2022 (UTC)[reply]
Services should be completely distinct from infrastructure I think. We have Q15141321 for train services. I agree this is all mixed up currently with properties such as vehicle typically used and rgb hex color applied to railway lines instead of services. For the terminus of the Kyle of Lochalsh Line Q586470 the Inverness terminus listed in Wikidata is the service terminus. But the Wikipedia article also notes the line starts at Dingwall.
Adjacent station should be a derived property ideally. By adding mileages using some variation of 'lineair references', adjacent station and terminus become a derivable property based on the time period, direction etc. Lnkvt (talk) 09:35, 16 September 2022 (UTC)[reply]
Yes, in principle one could derive adjacent station. And we probably will write such a query, to generate candidates. But I think it would be more than we could expect for example a Commons infobox template to undertake, to let it show the station in parentheses after the terminus (P559) terminus value, which I think would be nice. So I do think there is a case for identifying adjacent station (P197) values for terminating junctions, and also towards (P5051)} values if that is not where services typically terminate, and adding these.
I'm still turning over though what should most usefully constitute a "near enough" close match (Q39893184) to identify a ELR section (with its precisely defined ends) with a wiki article which may be slightly more extensive or encompassing. As an example (from the 'long sections' query above), consider Edinburgh to Carlisle Line (Q113992023). This represents essentially all of the Waverley Route (Q7975427) that is distinct to that route, rather than shared with other lines. On the other hand Waverley Route (Q7975427) does respesent the whole of the route from Edinburgh to Carlisle; whereas Edinburgh to Carlisle Line (Q113992023) only south from Millerhall. Is that good enough, because (as mentioned above), it's good to try to link things together & subjects to their most relevant references. And also perhaps one accepts that a wiki article in scope has slightly fuzzy edges, so may be alignable with a sharply-defined concept from elsewhere. (Unlike eg merging items for two concepts with sharp definitions that is different). Or do we think that this would be a conflation (Q14946528), to be avoided? Jheald (talk) 13:15, 16 September 2022 (UTC)[reply]
If I understand correctly, the Waverley line/service was closed and then reopened but with a deviation where services no longer run via Millerhill Depot but use a new section which runs west of the old route. The north end of the line has remained in use for freight. The new passenger service or line is called the Borders Railway. The razed section of the Waverley route from Millerhill Depot to Millerhill corresponds to part of NDE1 (the existing part of which forms the Waverley/Borders route north of ETC).
For me, the deviation, combined with the 6 miles north of Millerhill, is significant enough to consider them distinct. The fact that ETC has 'Edinburgh to Carlisle' as name is not that telling. Near Glasgow we findQ113892921 which is less than a mile long and goes nowhere near Kilmarnock. For that reason I chose to modify the label in Wikidata a bit compared to the name given in http://www.railwaycodes.org.uk/elrs/_mileages/g/gba.shtm.
The 'near enough' bits for me are distinctions like a branch line starting at station 'X' rather than junction 'X junction' which might be half a mile further. You do see those on the ELR site, as in http://www.railwaycodes.org.uk/elrs/_mileages/c/cjd.shtm where a mileage is given between brackets, Lnkvt (talk) 07:24, 17 September 2022 (UTC)[reply]
That makes sense. Also, merges are easy to do but can be a pain to unwind, so probably it makes sense anyway to tread carefully, and only do the most cast-iron cases first, at least until there's a much better sense of how everything tends to fit together.
I'm going to be away for a couple of days now; then I hope to get adding mileages and ELR links for stations and bridges; plus P131, connects-with, and terminus information for the sections themselves. Jheald (talk) 08:32, 17 September 2022 (UTC)[reply]

Thoughts[edit]

current ELR on a bridge plaque

I've been cataloguing images of railway bridge signs on commons, and adding images to Wikidata where needed. A few thoughts:

  • We say these are allocated by Network Rail, but the list contains codes that predate Network Rail, and the websites (and us) include BRB closed railways which also have three letter codes. Renfrew Branch (Q113961938) long predates network rail
Three letter code on disused bridge
@Secretlondon: Really nice. Lots of work in evidence at c:Category:Engineer's Line Reference ! I didn't know about bridge number (P9759). Per query https://w.wiki/6Fr8 (also these https://w.wiki/6FsN )I've now got some moving over to do, for the items where I had used catalog code (P528) as a substitute. Looks like I should change the qualifier too, from catalog (P972) = Network Rail infrastructure ID (Q114594493) to object has role (P3831) = Network Rail infrastructure ID (Q114594493).
As regards that descriptor item Network Rail infrastructure ID (Q114594493), I'd be very happy to see that have changes in name or description or statements. (At the very least, perhaps, to "Network Rail infrastructure ID"). I think I called the item Network Rail railway ID when I created it just because the column was called "Railway ID" on various spreadsheets, the spreadsheets being ones that Network Rail had sent out in response to various FoI requests. Very happy for it to be changed to anything else. As for the statement issued by (P2378) = Network Rail (Q1501071), I was guessing that they probably have ultimate authority over the codes now; but you're quite right to say they didn't originate them. So if you'd like to add British Railways Board (Q920016) with a start and end date as another value, that would seem to make perfect sense. When I created the item, I just wanted to put some statement on it to give an idea what it was, but as with any wd item, that's only the very first act of pushing a little paper boat into the stream, to be carried onwards to who knows where.
As for the commons images, I see we have a category c:Category:Railway bridge signs in the United Kingdom. I wonder if a thing to do would be to have that as a UK top-level category for these signs, with systematic sub-categories named c:Category:ELR:VIR bridge signs etc. If these had a corresponding Wikidata item with the statements instance of (P31) = Wikimedia category (Q4167836) and category combines topics (P971) = eg "bridge sign" & Victoria to Ramsgate (via Herne Hill and Chatham) Line (Q112872116), that should generate a decent infobox, displaying the relevant information from the parent ELR item. Then it wouldn't matter if some ELR items were used as synonyms for the whole line; and indeed we could more systematically add stations, infrastructure items, etc to relevant general Commons ELR categories.
As for structured data on the individual files, you may be right that bridge number (P9759) may not sit quite well on an image (as opposed to on an item for what the image is of) -- though there are properties that certainly do get 'stretched' for use on Commons. As an alternative, it might be entirely appropriate to tag the image with depicts (P180) = "bridge sign" with bridge number (P9759) as a qualifier. That would make them readily retrievable with a query. Jheald (talk) 13:29, 24 January 2023 (UTC)[reply]
A new property that could also be useful I think would be "nameplate image", usable for any identifying plates for locomotives, boats, houses etc -- and bridges (though not to replace place name sign (P1766) or traffic sign template image (P8505)). Jheald (talk)