Wikidata

Wikidata:Property proposal/Morse code

< Wikidata:Property proposal

Morse code edit

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Descriptioncode for a letter or number
RepresentsMorse code (Q79897)
Data typeExternal identifier
Domainitems for letters and numbers
Allowed values[.-]++
Example 1A (Q9659) → .-
Example 2E (Q9907) → .
Example 3H (Q9914) → ....
Example 4I (Q9893) → ..
Example 55 (Q203) → .....
Planned useadd to relevant items

Motivation edit

(Add your motivation for this property here.)
--- Jura 00:34, 11 August 2018 (UTC)[reply]

Discussion edit

  Comment @Jura1, Lymantria, Mahir256, Pasleim: So two more things that I feel need to be clarified here:
  • Are the spaces in the code significant? The regex (which as written is invalid by the way - the '-' should be first) allows space, dot, and dash characters. In the examples above there is a space between each dot or dash. I would have thought that, if anything, spaces should only appear between distinct character codes (for example if we are to add them for Chinese telegraph codes, you would need a space between the codes for each digit). Is there a standard that can be referenced to describe how this is traditionally done in plain text? To call it an "external id" we need to have a single universally agreed string format for the codes, you can't have various alternatives with different spacings etc.
  • We really need to pin down the domain. The international standard (ITU) Morse code only applies to the (capital) letters A-Z and digits 0-9. Do we intend to allow other characters or not? The enwiki page lists various extensions for punctuation and accented characters. Chinese has been suggested here, presumably a qualifier would be required to indicate the upper encoding. Are there other cases like this?
I think I could support it if it applied to significantly more than just the 36 standard ITU characters, but the proposal so far isn't clear on either of these questions. ArthurPSmith (talk) 20:33, 20 August 2018 (UTC)[reply]
  • No worries. I noted your oppose earlier about the proposal in its present form. Chinese telegraph codes wont work with the proposal in it's present form and they shouldn't.
    --- Jura 21:34, 20 August 2018 (UTC)[reply]
Ok,   Strong oppose then. But even so, you still haven't addressed the first question just above - why do you allow space in the regex (and have spaces in your examples) if you don't intend to allow this to be applied to anything other than the 36 characters? No morse code converter that I can find on the internet translates single characters to strings that have spaces, they are simple spaceless '...', '.-', etc. with the space character used to separate the code for one letter from another in a multi-letter string. ArthurPSmith (talk) 20:11, 21 August 2018 (UTC)[reply]
  •   Comment thanks for your feedback. I think there is sufficient support for this property to be created. I don't see a point in including [0-9] for Chinese codes, but except the opposer, I don't think any does. If there are problems with implementing it, we can discuss it later/improve the format.
    --- Jura 20:21, 21 August 2018 (UTC)[reply]
    • @Jura1: you are being overeager with a poorly prepared proposal. @Mahir256, ديفيد عادل وهبة خليل 2, Susannaanas, Pasleim, Lymantria: this is CLEARLY not ready as far as I can see, can one of you please comment in regard to the issues I've raised. And note that a very simple SPARQL query already returns the Morse code values for the letters (MINUS the spaces Jura inserted) - See tinyurl.com/y75euhhh . ArthurPSmith (talk) 20:32, 21 August 2018 (UTC)[reply]
      • I think that just illustrates the need for a separate property. We don't want Wikidata to be website with half the list.
        --- Jura 20:39, 21 August 2018 (UTC)[reply]
        • @Jura1: I was slightly disappointed that you didn't react to the spaces-question by ArthurPSmith, but I see below you have removed the spaces in the proposal. Thanks for that. Perhaps you could enlighten ArthurPSmith and myself to show benefit of this proposal in the use of for instance racon signal (P3994), as the signals this property is about are in fact morse codes. Initially I thought your proposal would allow us to add the morse code as qualifier to values of this property, that would make sense to me. I'm starting to doubt about the usefulness. Lymantria (talk) 05:40, 22 August 2018 (UTC)[reply]
            • @Lymantria: It's a point that was there from the beginning and had been discussed, we could continue to debate if the spaces should be there, small, smaller, large, etc. Anyways, with this property, a query should allow to convert the P3994 value to Morse. If the current list wasn't incomplete and we had checks in place to ensure it's robustness, it could also be done with the P3295/4 version. Unfortunately the current approach is somewhat unsatisfactory.
              Chinese codes could use the same to convert into Morse signals.
              --- Jura 05:49, 22 August 2018 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Morse_code&oldid=788065910"