Property talk:P215
Latest comment: 1 year ago by Huntster in topic New regex
Documentation
spectral class
spectral class of an astronomical object
spectral class of an astronomical object
[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/P215#single best value, SPARQL
Type “star (Q523), fictional star (Q17424291), brown dwarf (Q101600), binary star (Q50053), exoplanet (Q44559), multiple star (Q878367), sub-brown dwarf (Q1073768)”: item must contain property “instance of (P31)” with classes “star (Q523), fictional star (Q17424291), brown dwarf (Q101600), binary star (Q50053), exoplanet (Q44559), multiple star (Q878367), sub-brown dwarf (Q1073768)” 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/P215#Type Q523, Q17424291, Q101600, Q50053, Q44559, Q878367, Q1073768, SPARQL
Format “
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). (?:[\[(A-Za-z?\d]|:\+|<=?|>=?)[A-Za-z\d\-+*?\/()\[\]:\. _;,!~']*”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P215#Format, SPARQL
Qualifiers “reason for deprecated rank (P2241), reason for preferred rank (P7452), sourcing circumstances (P1480)”: this property should be used only with the listed qualifiers. (Help)
List of violations of this constraint: Database reports/Constraint violations/P215#allowed qualifiers, hourly updated report, SPARQL Scope is as main value (Q54828448): the property must be used by specified way only (Help)
List of violations of this constraint: Database reports/Constraint violations/P215#Scope, hourly updated report, SPARQL
Citation needed: the property must have at least one reference (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/P215#citation needed
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/P215#Entity types
|
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
| ||||||||||||||||||||||||||||||||||
We need one text/acronym property, and one item property edit
I think the datatype should be item instead (e.g. en:S-type_asteroid), which might be linked to a generic acronym property ("S"). Mange01 (talk) 10:48, 7 March 2013 (UTC)
- You are right for asteroids, but this property was proposed for stars. I'm sorry for the mistake: I have just corrected the infobox parameter example with the link to the correct template and the example values. Thank you very much for your observation! --Paperoastro (talk) 13:42, 7 March 2013 (UTC)
- Ok. Anyway, I have now suggested a generic Code property. Should we suggest an "asteroid type" of datatype item, or is it enough with using "is a(n)" for that purpose? Mange01 (talk) 16:54, 7 March 2013 (UTC)
- For me is the same, but in old discussions, the community seems to prefer more specific properties (for this reason I ask the undeletion of Type of astronomical object property). So, probably it is better to suggest "asteroid type" of datatype item, as you told before. Concerning the interesting Code property, I gave my opinion in the "property proposal" page. --Paperoastro (talk) 17:22, 7 March 2013 (UTC)
- Ok. Anyway, I have now suggested a generic Code property. Should we suggest an "asteroid type" of datatype item, or is it enough with using "is a(n)" for that purpose? Mange01 (talk) 16:54, 7 March 2013 (UTC)
format constraint edit
the pattern (d|esd|g|sd|wd|w|) means any of the strings "d", "esd", "g", "sd", "wd", "w" or "". empty string could also be reached by adding a ? after the bracket. the pattern [O|B|A|F|G|K|M|DA|DB|DC|DO|DQ|DX|DZ] means any of the characters "O", "|", "B", "A", "F", "G", "K", "M", "D", "C", "Q", "X" or "Z". this is not what was intended. if someone gives a desription of how the string should look like, i will write a regular expression that matches it. or give a list of valid and invalid values. --Akkakk 09:22, 17 August 2013 (UTC)
- Hi Akkakk, thank you very much for your comments and your offer of help. For my self-interest, I'm learning regular expression and I'm trying to make the correct expression using also your suggestions. I found a nomenclature for star classification here. I you want to give a look, you are welcome. --Paperoastro (talk) 21:42, 20 October 2013 (UTC)
New regex edit
In order to accommodate a wider array of spectral types, some changes are needed to the regex. I came up with the following:
- (sd|D)?[OBAFGKMCLTY]\d(\.\d)?(VII|VI|V|IV\/V|IV|III\/IV|III|II\/III|II|I\/II|I|0)?(a-O|a|ab|b)?(\:|comp|e|f|m|n|nn|neb|p|s|sh|var|wl|\!|\*|\+)*
- Syntax clarification: "optional dwarf type + temperature class + luminosity class + luminosity subclass + precisions + peculiarities"
which provides for optional dwarf types (sd and D), expands the temperature classes (C, L, T, and Y), simplifies the luminosity classes by separating class and subclass (which is also useful because, in practice, the subclasses are used by more than just "I"), and expands on peculiarities. Unfortunately, something is wrong with the code, because even expected violations were not being flagged. If someone could help me out with this, I would appreciate it. Regex is confusing. Note that its still not perfect, because I have no idea how to accommodate things like Betelgeuse's "M1-M2Ia-Iab".
Sources:
- http://www.star.ucl.ac.uk/~pac/spectral_classification.html
- https://skyandtelescope.org/astronomy-resources/the-spectral-types-of-stars/
- https://lweb.cfa.harvard.edu/~pberlind/atlas/htmls/note.html
— Huntster (t @ c) 07:22, 1 February 2022 (UTC)
- @Huntster: hi, 31% of current statements violate format constraint. Any suggestions? --Lockal (talk) 06:33, 7 September 2022 (UTC)
- Lockal, unfortunately that's the nature of our ever-improving ability to refine the nature of stellar objects, and finding new esoteric varieties. Honestly, it might be better to do away with the regex. When you have instances like SDSS J122859.93+104032.9 (Q31888190), IC 1295 (Q1653282), and HR 5171 (Q10905104) (and I've seen even less tame combos), trying to account for every scenario becomes completely unmanageable. — Huntster (t @ c) 13:27, 7 September 2022 (UTC)
- This probably works better:
(?:[\[(A-Za-z?\d]|:\+|<=?|>=?)[A-Za-z\d\-+*?\/()\[\]:\. _;,!~']*(query). At least it does not trigger 235248 violations. --Lockal (talk) 05:56, 9 September 2022 (UTC)- If you think that is an appropriate solution, then by all means. — Huntster (t @ c) 16:19, 9 September 2022 (UTC)
- This probably works better:
- Lockal, unfortunately that's the nature of our ever-improving ability to refine the nature of stellar objects, and finding new esoteric varieties. Honestly, it might be better to do away with the regex. When you have instances like SDSS J122859.93+104032.9 (Q31888190), IC 1295 (Q1653282), and HR 5171 (Q10905104) (and I've seen even less tame combos), trying to account for every scenario becomes completely unmanageable. — Huntster (t @ c) 13:27, 7 September 2022 (UTC)