Support - have you also considered using "ignition point = 100 °C" with a qualifier "ignitions conditions (item) = autoignition, flame point, ...". --Tobias1984 (talk) 18:29, 8 July 2013 (UTC)
Why not. But how many different ignition temperature do we have ? The most common temperature are flash point and autoignition temperature. There is still the ignition temperature but this is not widely used as characteristic criterion. So if we have only 2 properties we don't save anything by creating one general property and one qualifier. Snipre (talk) 12:07, 10 July 2013 (UTC)
That is true. We might even need those qualifiers for measurement conditions or something. --Tobias1984 (talk) 08:45, 19 July 2013 (UTC)
Comment couldn't this and the next property be modelled simply with the property temperature and qualifiers instanceof (Flash Point, autoignition) and pressure? — Felix Reimann (talk) 23:03, 9 August 2013 (UTC)
Support Having Autoignition as a separate property would make it easier to access from an infobox. Macadamia1472 (talk) 06:13, 16 October 2013 (UTC)
Support. datatype changed. This should be a sub-property of Temperature. Joe Filceolaire (talk) 21:41, 12 September 2015 (UTC)
Future importation of Pocket Guide to Chemical Hazards into Wikidata
This is valuable safety information that I would like to import as part of my importation of the Pocket Guide to Chemical Hazards into Wikidata. James Hare (NIOSH) (talk) 16:44, 24 September 2015 (UTC)
Future importation of Pocket Guide to Chemical Hazards into Wikidata
This is valuable safety information that I would like to import as part of my importation of the Pocket Guide to Chemical Hazards into Wikidata. James Hare (NIOSH) (talk) 16:48, 24 September 2015 (UTC)
Future mass importation of the Pocket Guide to Chemical Hazards into Wikidata.
This is important chemical safety information that will be included as part of the importation of the Pocket Guide to Chemical Hazards into Wikidata. James Hare (NIOSH) (talk) 17:50, 24 September 2015 (UTC)
Comment Is there really a standard value ? Concentration is not enough, particule size is important too. Snipre (talk) 23:09, 27 September 2015 (UTC)
Snipre, the standard for testing minimum explosive concentration is ASTM E1515. While not considered an "absolute" measurement, it is a way by which dust clouds of different substances can be compared on the basis of their explosiveness. James Hare (NIOSH) (talk) 13:49, 1 October 2015 (UTC)
Support For controlled vocabulary we should probably include the organization in the title. I would suggest "minimum explosive concentration according to ASTM E1515" --Tobias1984 (talk) 17:51, 4 October 2015 (UTC)
Part of future mass importation of the Pocket Guide to Chemical Hazards into Wikidata.
This is part of a mass importation of data from the Pocket Guide to Chemical Hazards into Wikidata. There are multiple first aid responses for each chemical depending on the route of exposure and toxicity of that particular chemical. Once the chemical route of exposure property is created, I can associate that with each first aid-related item that I created so that it is clearer which is associated with which route of exposure. James Hare (NIOSH) (talk) 19:16, 25 September 2015 (UTC)
Support But I would just call it "first aid measures" or something more general. This property could also be used for items for injuries and topics in emergency medicine. --Tobias1984 (talk) 12:05, 5 October 2015 (UTC)
Motivation. GZWDer (talk) 16:30, 30 November 2013 (UTC)
I don't think LDLo, LD50, LD100, etc. should be merged together. --Leyo 14:45, 3 December 2013 (UTC)
Support But I would prefer one property for each different concept because for toxicity we have already the species or the different conditions like the experiment duration for concentration as qualifier. as first target I propose to have one property for LD50, we can wait a little before creating two other properties for the LDLo and LD100 which are not used in the same extend as for LD50. Snipre (talk) 12:30, 29 January 2014 (UTC)
Comment. I agree with Snipre: we should have different properties for all the different toxicity metric. I also think these properties should be taxon-specific, since qualifiers will not be queryable in the foreseeable future. So we should start with LD50 for humans. I'd recommend proposing these properties in a batch, so we're not waiting 3 months to get these properties created. Emw (talk) 05:45, 1 February 2014 (UTC)
Support - looks useful. --Jakob (talk) 16:08, 2 February 2014 (UTC)
@Pigsonthewing: The Freebase link does not work for me at the moment, so I can't look at the exmaple. I think the proposal needs a more general discussion on how things like this should be handled. The measure is meaningless without knowing (1) how it was calculated and (2) what the calculated uncertainty is (3) if it is given as a fraction, percentage or in absolute values. For example en:Copernicium even has an asymmetric uncertainty: 357 (+112/−108)K given in the absolute measure and the mode of calculation should be mentioned in the source. I am not sure the number-datatype can handle this complexity. We need some kind of datatype that gives us a few fields for all these values. For example Uncertainty: (Field 1: +Uncertainty)[Number], (Field 2: -Uncertainty, Optional: only use when asymmetric)[Number], (Field 3: Relative, Absolute)[Item], (Field 4: Mode of Calculation)[Item]. --Tobias1984 (talk) 13:24, 18 June 2015 (UTC)
Not done @Pigsonthewing: I think we need a property to express uncertainty in the qualifiers (e.g. "uncertainty corresponds to" = "1 sigma"). But I think it needs a fresh start with a new proposal. --Tobias1984 (talk) 11:18, 15 October 2015 (UTC)
Part of future mass importation of the Pocket Guide to Chemical Hazards into Wikidata.
This is part of a mass importation of data from the Pocket Guide to Chemical Hazards into Wikidata. James Hare (NIOSH) (talk) 18:12, 24 September 2015 (UTC)
Comment Currently I think we can calculate relative densities from all the abosolute densitities. This also avoids that we have to define "standard air density". --Tobias1984 (talk) 17:39, 4 October 2015 (UTC)
Not done Not enough support. Alteranative probably works. --Tobias1984 (talk) 11:19, 15 October 2015 (UTC)
Weak oppose I think we already discussed a similar property once, and I think the consensus was to use multiple values of subclass of (P279) for each element. An element can be part of a block and a period. Infoboxes can ask for all the subclass of (P279) values, and with arbitrary data access ask for which p279 leads to a block, and which p279 statement leads to a period. --Tobias1984 (talk) 13:29, 18 June 2015 (UTC)
@TomT0m: Thank you. My request was for a link to the previous discussion of "a similar property" to the one proposed, and an example - if one exists - of where the model for periodic table blocks proposed by Tobias1984 is already used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:22, 18 June 2015 (UTC)
Weak oppose generic classification tools can handle this. As long as we have a good definition for the s-block element metaclass, which seems to me pretty clear (but I'm not an expert). TomT0m(talk) 16:27, 18 June 2015 (UTC)
Oppose. To specialised a property. Just use 'subclass of'. Joe Filceolaire (talk) 16:01, 2 August 2015 (UTC)
Support Seems straight forward. --Njardarlogar (talk) 21:22, 15 February 2013 (UTC)
Support it is necessary for infobox. Sunpriat (talk) 19:43, 6 October 2014 (UTC)
Is there any reason to not add this already? Regardless of whether we want more specific mass properties (below) for certain things or not, we will still need a generic mass property. - Nikki (talk) 11:42, 12 September 2015 (UTC)
I think it's better to start out with the specific ones. --- Jura 12:00, 12 September 2015 (UTC)
I asked if there's a reason to not add it. - Nikki (talk) 11:15, 13 September 2015 (UTC)
Qualified support'. It should be a quantity, not a number, because all the features of quantities should apply.
I agree with defining the value that can be assigned to a mass in accord with the Number/Quantity datatype description suggested by Joshbaumgartner (talk • contribs • logs). But I read that document differently. It says "A QuantityValue represents a decimal number, together with information about the uncertainty interval of this number, and a unit of measurement." Within that document a number is only one component of a QuantityValue, the other components being the uncertainty interval and the unit of measurement. Jc3s5h (talk) 18:53, 15 September 2015 (UTC)
Strong support This is most basic and necessary. More specific ones may be warranted, but this baseline should be implemented now, with special cases handled downstream from it. Josh Baumgartner (talk) 18:04, 15 September 2015 (UTC)
Comment we have a general mass property pending but I don't think we can use it because that would require too many qualifiers. I don't know how the number type will work and how it will work with physical units (do we set it to kg when creating it or can the unit be chosen by the person entering the data?). We should also look into if "u" can be added as a physical unit. For atoms we should probably use different isotopic values (for hydrogen the common value would be 1.007947). We probably should think about qualifiers for estimated isotopic ratios, reservoir in which the ratio was measured, etc... For items about isotopes we could think about creating a separate property because the value is much more straight forward (H1 = 1.00782504). If we use it for atoms, isotopes, particles and molecules it could apply to a lot more items. --Tobias1984 (talk) 15:21, 14 August 2013 (UTC)
Comment. Before to support this property, I have a question: I don't know how the future number datatype will work, but should have also a measure unit. Could be sufficient? --Paperoastro (talk) 20:07, 14 August 2013 (UTC)
That is precisely the reason why all votes and comments on non-existing datatypes are so irrelevant. We really don't know how they will work. If the property "mass" has kg hard-coded into it then we can't add values in "u" because there is a conversion factor as you know. I guess people could add the values in kg or maybe the user will be allowed to choose the physical unit. Again, all this is irrelevant as long as the datatype doesn't exist. And before any pending proposal is created we have to do a very thorough check. --Tobias1984 (talk) 09:07, 18 August 2013 (UTC)
I would expect that a user be able to change what units he is entering the information in, but maybe that's just a pipe dream. :) I should hope there's a user preference for the display of the units, however. --Izno (talk) 00:01, 21 August 2013 (UTC)
Support I think that atomic mass is sufficiently abstract from conventional mass to be granted its own property. Macadamia1472 (talk) 05:40, 16 October 2013 (UTC)
Support. A general “mass” property is IMO unsuitable for this purpose because, e. g., the item hydrogen (Q556) is about hydrogen in general, not about a single hydrogen atom (there are other physical properties of hydrogen that don’t even apply to individual atoms). Thus, it would be wrong to say that 1.01 units is the mass of hydrogen (Q556). —Galaktos (talk) 14:29, 14 September 2015 (UTC)
@Galaktos: That depends of the definition of "hydrogen" and "chemical element" you take into account. French "élément chimique" article and english "chemical element" one do not agree. For the english one, "chemical element" is a pure substance, in the french case, un "élément chimique" is a type of atom. This is actually an interwiki conflict, but in the french case, yes, we're talking of the mass of an atom. In the english one, we're not really talking of the mass of an atom, but the mass of each the substances we call "Hydrogen", so it seems closer to a molar mass (Q145623) imho ... author TomT0m / talk page 14:40, 14 September 2015 (UTC)
TomT0m: From you paragraph above it is clear that using a generic mass property for this will create a real scope for misunderstandings. For me this is enough reason to have a specialist property like atomic mass. Joe Filceolaire (talk) 14:56, 14 September 2015 (UTC)
@Filceolaire: I don't agree. There is room for a property molar mass (Q145623) because it has a different unit, g.mol-1, but for the mass of an hydrogen atom, a countable object, there is no need of that. For substances on the other hand, this is a different question because we can have different kind of masses : mass per volume, for example, and if we refer to a class of substances we know nothing about the instances, for example if an instance of hydrogen (as a substance) is an hydrogen bottle (its content actually) then we have to know at least the volume or the pressure to know the actual mass of the content. The real way to avoid confusions is to clearly define if we're talking of a class of substances or a class of atoms, by having an item for each. An "atom mass" property will not help. author TomT0m / talk page 15:07, 14 September 2015 (UTC)
Support as this is the mass of one atom of the element, not the total mass of the element. We could have a separate item 'hydrogen atom' and use property 'mass' for that, but that seems too clunky. Josh Baumgartner (talk) 18:18, 15 September 2015 (UTC)
@Joshbaumgartner: It's not we could, it's that we WILL have. If we don't already have, see my comment. author TomT0m / talk page 18:44, 15 September 2015 (UTC)
Oppose use generic mass property with appropriate unit instead. --- Jura 22:34, 28 September 2015 (UTC)
Oppose - Mass is a generic property. A qualifier can say "measured" linking to an item that says "empty". --Tobias1984 (talk) 14:01, 16 May 2013 (UTC)
Support 'Empty weight' is a very common specification for aircraft, not 'empty mass' or 'mass measured when empty'. Relying on qualifiers complicates data entry and retrieval, so I am supporting having discrete properties for 'empty weight', 'loaded weight', and 'maximum takeoff weight' (the three primary weights used in aviation specifications). Joshbaumgartner (talk) 05:21, 13 October 2013 (UTC)
Support. Mark it as <subproperty of:Mass> so that (when we get a "search (including subproperties)" tool) we can search on generic mass and pick up this. Joe Filceolaire (talk) 15:15, 12 September 2015 (UTC)
Support. Essential to aircrafts. Poul G (talk) 15:32, 13 September 2015 (UTC)
Oppose - Mass is a generic property. A qualifier can say "measured" linking to an item that says "gross". --Tobias1984 (talk) 14:01, 16 May 2013 (UTC)
Support Same as the 'empty weight', 'maximum takeoff weight' is a standard terminology in aviation (though 'gross weight' may be commonly used in gliding). While I understand the technical scientific distinction of mass vs. weight, the broad usage of the term and the data it represents are enough to warrant it having its own distinct property available. Joshbaumgartner (talk) 05:35, 13 October 2013 (UTC)
Support But I would recommend renaming it to 'maximum take-off weight' if it is exclusive to aircraft. Macadamia1472 (talk) 06:48, 14 October 2013 (UTC)
Comment English name and description updated accordingly. We should add the AKA upon property creation. Joshbaumgartner (talk) 00:28, 27 October 2013 (UTC)
Support. Essential to aircrafts. Poul G (talk) 15:33, 13 September 2015 (UTC)
Comment - also applicable to any cargo carrying machinery.
Probably not applicable to any cargo carrying machinery. Payload is a specific term "carrying capacity of an aircraft or space ship, including cargo, munitions, scientific instruments or experiments. Extra fuel, when optionally carried, is also considered part of the payload." quote from Payload (air and space craft). There are weight systems for other types of transport, but the actual weights can vary between one vehicle and another (instances of), depending on other specifications such as the engine fitted. A truck which has a crane fitted can carry less due to the weight of the crane. Danrok (talk) 16:11, 22 May 2013 (UTC)
Support Applicable to many fields, including robotics.--Micru (talk) 22:14, 22 August 2013 (UTC)
I wonder if "payload" is a good way to call this, given that we also call the various subsystems as mentioned by Danrok "payloads". This property might better be named "maximum payload weight"? --Izno (talk) 23:39, 22 August 2013 (UTC)
Good call, I have changed the title as per your suggestion.--Micru (talk) 14:00, 26 August 2013 (UTC)
Support. Essential to aircrafts. Poul G (talk) 15:34, 13 September 2015 (UTC)
SupportDanrok (talk) 10:24, 2 September 2013 (UTC)
Question - is this really specific to aircraft? What about ships, trucks, train cars? ArthurPSmith (talk) 15:26, 14 September 2015 (UTC)
In English at least they aren't typically expressed in this way - maximum gross weight is more typical for road vehicles, and for ships I'd expect it to be expressed as tonnage. However "maximum payload weight" could I think be used for spacecraft, although the infobox at w:Space Shuttle has several different maximum payload weights listed (which may be needed properites here themselves, I'd need to do more research before proposing them myself though). Thryduulf (talk: local | en.wp | en.wikt) 14:53, 15 September 2015 (UTC)
Support Seems reasonable to me. author TomT0m / talk page 13:31, 13 September 2015 (UTC)
I agree with Tobias1984's proposition for only one generic property. --Casper Tinan (talk) 18:58, 13 September 2015 (UTC)
Support makes sense -- Bene*talk 06:54, 14 September 2015 (UTC)
There should be a property for the mass/weight of the item, but we should not try to force everything that represents a mass to use that property. If something does not refer to the weight of the item itself (e.g. "maximum payload weight" above), it should be a different property. If something does refer to the weight of the item itself, I would prefer subproperties over repeatedly using a small set of qualifiers, but I think subproperties would need to be considered on a case by case basis. - Nikki (talk) 12:42, 14 September 2015 (UTC)
Support Agreed. For instance, atomic mass is the mass of a single atom, not of the element itself, so it would be wrong to use a generic mass property on the item (which represents the element, not a single atom). —Galaktos (talk) 14:35, 14 September 2015 (UTC)
No. We can't avoid different mass properties when different values is possible for the same item. But we don't need specific properties according to the field of items: the property for the mass of a car can be the same for the mass of a person. But the dead weight and the weight at full load of a boat or plane can't be described by an unique property. We should at least add qualifier. I think we should group the mass properties and see what is the minimal amount we can have.
If I take the above proposal, we can group:
atomic mass = mass of a person = Empty weight = mass -> one property
maximum payload weight -> one property
Theoretically Empty weight + Maximum payload weight is equal to Maximum takeoff weight, so no need of additional property, but I don't know the definition of maximum payload weight (include or not the fuel, the ammunition,...).
Yes and No. I think we should have specific properties like empty weight, laden weight, etc. but I am opposed to weight of person because that is easily determined from the instance of claim. I think I this pretty well matches the other opinions above. Joe Filceolaire (talk) 14:34, 14 September 2015 (UTC)
Support Start with one. A limited number of widely used basic properties are going to be easiest to work with. If subproperties can be made to work reasonably then a few or even a large number of subproperties might not be a problem, but as I understand it there's not a lot of support for subproperty-based constraints right now. ArthurPSmith (talk) 14:57, 14 September 2015 (UTC)
Of course the basic property mass (P2067) is necessary and should cover most early needs, but more specialized mass-related properties ought to be created normally as they are needed and go through the proposal process. I don't see a reason to hold them up artificially. Josh Baumgartner (talk) 00:55, 16 September 2015 (UTC)
Because the property proposal process is exhausting. We discussing very specific properties in a vast variety of cases and the number of proposal wrt. weight could be huge. Giving community a little time to digest before taking a lot of decisions, maybe non consistent with each other considering the process as he is, could be a good thing. author TomT0m / talk page 07:51, 16 September 2015 (UTC)
Done I created the generic property for mass. I think it is good to let the community try out how far we can stretch the generic property and then start new discussions for more specific mass propeties. --Tobias1984 (talk) 17:38, 15 October 2015 (UTC)
Property might be useful for automatic generating readable descriptions from statements for languages using latin scripts if object name is not available in any readable script in user language. Paweł Ziemian (talk) 14:09, 28 June 2015 (UTC)
Support, I was about to propose it after working on quite a lot of japanese items :)
by the way, could you please provide a simple online automatic converter ? I could not find one that worked : only long pages of explanations :/ --Hsarrazin (talk) 17:58, 1 August 2015 (UTC)
I would not recommend using a simple online automatic converter. Japanese writing and romanisation are not very straightforward, so it's not easy to make an accurate converter and if you don't know how Hepburn transliteration works, how will you know if the output of a converter looks correct? - Nikki (talk) 08:45, 4 August 2015 (UTC)
Thanks a lot for your answer. Did not know if it was something that existed or not. If not "automatic", you're right, better avoided :) --Hsarrazin (talk) 17:23, 7 August 2015 (UTC)
Property might be useful for automatic generating readable descriptions from statements for languages using latin scripts if object name is not available in any readable script in user language. Paweł Ziemian (talk) 14:18, 28 June 2015 (UTC)
Support - working with Georgian names is really painful - can you please provide an online converter (if one exists ?) --Hsarrazin (talk) 18:01, 1 August 2015 (UTC)
Property might be useful for automatic generating readable descriptions from statements between languages with Cyrillic and Latin scripts if object name is not available in any readable script in user language. Paweł Ziemian (talk) 14:33, 28 June 2015 (UTC)
I would tend to support this property. The problem I would identify is that of multilingual piece of it, however. The French for (example) "Bill" is not the same as the English for Bill, so transliterating to Cyrillic from either language is going to have a different transliteration. Also, I'm not sure why we would use it as a qualifier for claims of the Wikibase Entity type rather than only for those of the String type. --Izno (talk) 19:35, 10 July 2015 (UTC)
I was wrong. The conversion works only from Cyrillic to Latin script, but the process is fully reversible and language independent. Fixed. Paweł Ziemian (talk) 20:53, 10 July 2015 (UTC)
Support - I was about to propose this creation myself :) --Hsarrazin (talk) 18:03, 1 August 2015 (UTC)
There are actually multiple versions of ISO 9, I think it would make sense for us to specify which version we mean - presumably the most recent, ISO 9:1995. - Nikki (talk) 19:34, 29 August 2015 (UTC)
Support for ISO 9:1995 --Pasleim (talk) 19:34, 4 October 2015 (UTC)
Some properties for quantities, like elevation above sea level (P2044), are meaningful only in relation to some base value. That base value (e. g. height above sea level) can be given with this statement. (In the case of height, a more specific name for the property would be “above”.) Galaktos (talk) 20:26, 9 September 2015 (UTC)
Comment P2044 was originally labelled “height”. It has since been changed to “elevation above sea level”, which IMO is a mistake, since there’s no such thing as a single sea level – you need the property proposed here to specify which level the value is relative to. (There are lots of national standards for elevation measuring.) —Galaktos (talk) 12:19, 12 September 2015 (UTC)
Interesting. We certainly need a property for that too (“density: 19.32 g/cm³ at 20°C”), but I’m not sure if it’s possible to phrase this property sufficiently general that it can support both use cases.
@Filceolaire: On the P2044 talk page it was proposed to use determination method (P459) as a qualifier. I guess that could be used instead of this proposal, and also to record the conditions for a measurement (your proposal). Do you agree? —Galaktos (talk) 13:54, 14 September 2015 (UTC)
Actually I don't think I do. determination method (P459) is about the method or process used to make a measurement. For elevation above sealevel this would be triangulation or satellite rangefinding etc. This is independent of the sealevel reference used in displaying the elevation. so I think we need both properties. Joe Filceolaire (talk) 14:20, 14 September 2015 (UTC)
Hm, good point. And I still can’t think of a phrasing that supports “height relative to” and “measurement conditions”, so I think we need all three properties. —Galaktos (talk) 20:35, 14 September 2015 (UTC)
Can't we generalize this to something like reference point ? author TomT0m / talk page 08:09, 15 September 2015 (UTC)
In the case of elevation above some sort of quasi-sea-level, the elevation is above a surface of some sort, which may be an ellipsoid of revolution, or a geoid (which is an irregular surface with no simple mathematical description). So "reference point" is not the right phrase. Jc3s5h (talk) 13:27, 15 September 2015 (UTC)
Jc3s5h: In most of the cases that this property is to be used with, the elevation is not measured above some quasi-sea-level. It is measured above a mark on a pier in a harbour somewhere - a datum. This is usually called the "high water mark" or something similar and was fixed back in the 1800's when they started the national geographical survey - though it may have been updated more recently. en:ordnance datum has info on the British datum and the Irish datum. Joe Filceolaire (talk) 12:19, 18 September 2015 (UTC)
A description of how this is done in the US is given at the FAQs for the National Geodetic Survey website. See the question "What are NGVD 29 and NAVD 88? How do the horizontal datums differ? Which should I use?" Sure, elevations in the US are determined by holding fixed the elevation value (around 7 metres) of the primary tidal bench mark, referenced to the new International Great Lakes Datum of 1985 local mean sea level height value, at Father Point/Rimouski, Quebec, Canada. But that point isn't assigned the value 0, and the method of relating a particular elevation to it requires following many rules associated with the datum (in this case, North American Vertical Datum of 1988). Those rules include sophisticated least-squares analysis of many observations at many points. So it is much better to say the elevation is found with respect to a particular named datum rather than a particular bench mark at the mouth of the St. Laurence River
Comment The example yields "The requested URL was not found on this server." if one wants to see the table of contents or read the book in any most of the formats advertised. But the TIFF version seems always present (don't let the initial empty pages mislead you). Also the domain is not works but editions, so the example would have to be connected to a currently not existing item for the particular 1931 bengali edition of that work of 1882 comparable to the three items for english language editions Dawn over India (Q19795188), Abbey of Bliss (Q19795166) and s:Anandamath (Aurobindo) (no wikidata item yet). -- Gymel (talk) 10:11, 13 June 2015 (UTC)
Anandamath (Q3124055) for the "book" most probably stands for the work, not the 1938 edition. Otherwise the has edition or translation (P747) and most sitelinks would not make sense at all. Probably the confusion arises because the sitelink do bn:Wikisource  is misplaced here, it must be moved to an item of its own. -- Gymel (talk) 23:37, 14 June 2015 (UTC)
OK, but I think we are getting sidetracked. Let us accept that DLI links, like IA, are edition-specific and not work-specific, and move on from there. Hrishikes (talk) 03:12, 15 June 2015 (UTC)
On further looking out, I see that most links are edition-specific, including OCLC, ISBN, Gutenberg etc. The versions pages in Wikisource are work-specific, which is limited to a small number of works having multiple versions; but the normal run of Wikisource links are edition-specific. So the DLI links are appropriate and helpful in authority control. Hrishikes (talk) 17:32, 16 June 2015 (UTC)
to be determined, probably Mix 'n' Match will be used
Wikimedia Italia is planning to upload its own list for Wiki Loves Monuments on Wikidata, in order to facilitate the composition of lists and the enrichment of monuments' items on Wikidata with data.
This is a pilot project that will interest in a first, experimental phase only a short list of sites in Emilia-Romagna (Q1263), but with time it will be extended to all Italian region.
We sincerely hope that other Wikimedia chapters/user groups will join, but first we want the experimentation to succeed. :) Sannita - not just another it.wiki sysop 10:10, 6 September 2015 (UTC)
Does this have a "formatter url"? Do these have national reference numbers as well? What is this reference used for? Will this reference be replaced by the item Qid when all these have wikdata items? Joe Filceolaire (talk) 21:49, 6 September 2015 (UTC)
@Filceolaire: Sorry for being this late in answering. About formatter urls, no, WM-IT doesn't use them (yet).
About national references numbers, unfortunately there are several reference numbers. What you probably don't know is that there is no unique national registry for monuments in Italy, but there is a plurality of registries, depending on the type of monument or area. Basically, the WLM code is used to make a connection between the Ministry's registry and the regional/local registries (which are not connected to each other).
Sannita; Every one of these monuments will have an item here on wikidata. Each of those items will have a unique Wikidata ID - a number with a Q prefix. Why can't we use the wikidata ID instead of the WLM ID? That is the ID which will be around in the future and which will have all the database manipulation tools and goodies which will be built around wikidata.
If the answer is that the WLM ID is useful for now until a better workflow based on wikidata arrives then that is probably a good enough reason to have it - we can always delete it next year. Joe Filceolaire (talk) 14:32, 12 September 2015 (UTC)
@Filceolaire: Sorry again for being late. This is a harsh period for me with both WM-IT and work-related problems.
Yes, the answer is "the WLM ID is useful for now, until a better workflow based on wikidata arrives". My hope is that we (communities+chapters) will think and prepare such workflow in time for WLM 2016, still we need to get started somehow. ;) Sannita - not just another it.wiki sysop 23:07, 22 September 2015 (UTC)
Support if you really can't get around that .. --- Jura 10:38, 15 September 2015 (UTC) Comment we already have specific properties to link to other Wikimedia-related projects, this would just make it another one. --- Jura 09:07, 1 October 2015 (UTC)
SIGIC is the main music information database in Slovenia. The main source of data is the Ministry for culture of Republic of Slovenia. A web portal was created in 2010 and renewed in 2011. URL adress uses ID numbers for three categories of objects (see examples above): avtor (author), zasedba (music group) and institucija (institution). That means that three separate SIGIC properties should be created. --Janezdrilc (talk) 13:30, 9 September 2015 (UTC)
Support all three. Can you do the template three times with the three different property names so we can track all three properties? Joe Filceolaire (talk) 14:35, 12 September 2015 (UTC)
Ok, I have changed the template above and added two separate templates below, each for one category of URL. --Janezdrilc (talk) 21:48, 18 September 2015 (UTC)
Thank you for support. --Janezdrilc (talk) 00:47, 11 October 2015 (UTC)
The United Nations Standard Products and Services Code (UNSPSC) is a taxonomy of products and services for use in eCommerce. It is a four-level hierarchy coded as an eight-digit number, with an optional fifth level adding two more digits. The codeset is available in English, French, German, Spanish, Italian, Japanese, Korean, Dutch, Mandarin Chinese, Portuguese, Danish, Norwegian, Swedish, and Hungarian. PDF versions of the codeset are available for free download. A version in Microsoft Excel format is available to members, who can also request changes and suggest additions to the code.
Mix N'Match welcome since there are over 50 000 items
This provides a hierarchical, curated identifier for many articles. It also links with many systems (ranging from national procurement systems, to UN organisations…) using the system. Teolemon (talk) 21:55, 12 September 2015 (UTC)
BiblioNet is the only accessible database of book editions published in Greece, created by the National Book Centre of Greece.
Also, a database of all authors, including writers, editors, translators, illustrators, photographers etc. listed as contributors in books.
-gerakitalk 07:59, 14 September 2015 (UTC)
BiblioNet is the only accessible database of book editions published in Greece, created by the National Book Centre of Greece.
Also, a database of organisations and businesses etc. listed as publishers in books.
--gerakitalk 08:10, 14 September 2015 (UTC)
Identification Number of Fantastique Literature (NILF)
A bot would have to be written to match the entries
NILF (Numero Identificativo della Letteratura Fantastica) is an identifier (for authors and works) used in
the Catalogo Vegetti, an italian collaborative catalogue of fantastique
Very similar to ISFDB catalogue, that has already its own property in wd https://www.wikidata.org/wiki/Property:P1233
Having NILF identifier on wikidata could permit to match and augment linking between the Vegetti, ISFDB, Wikipedia.
Comment a better name of the property could be NILF author id (identifier for a person in the Catalogo Vegetti). i think that is better to specify that is for authors only, as P1233, because Vegetti use the same identifier also for books and publishers. Atomotic (talk) 09:45, 19 September 2015 (UTC)
Bots could be created to import this using the templates.
Soccerbase is a database of mainly European soccer results and statistics, run by the Racing Post. It has various IDs, including for managers, so could be used for authority control, and as a useful source of information. There are templates that we could import from, and there are 17 apparently equivalent ones for different languages we could use to help verify the data quality, and cover a wide range of managers. Silverfish (talk) 15:36, 6 September 2015 (UTC)
Bots could be created to import this using the templates.
Soccerbase is a database of mainly European soccer results and statistics, run by the Racing Post. It has various IDs, including for players, so could be used for authority control, and as a useful source of information. There are templates that we could import from, and there are 31 apparently equivalent ones for different languages we could use to help verify the data quality, and cover a wide range of players. Silverfish (talk) 15:36, 6 September 2015 (UTC)
May be very useful property for various criminals and some organizations. Qualifiers may also be added in the future such as by whom the subject was arrested (E.g. police, FBI, etc.) or which crime suspected of. Nonexyst (talk) 09:25, 14 September 2015 (UTC)
Oppose I don't think multiplying dates and location property for each and every type of event is a good thing. significant event (P793) can do the trick. --Casper Tinan (talk) 20:19, 14 September 2015 (UTC)
Oppose, per Casper Tinan. --Yair rand (talk) 22:53, 16 September 2015 (UTC)
Oppose There is also "river kilometer", and I see no reason to have two independent properties for the same concept. Better to have one that represents both, and then display the wished unit.--Micru (talk) 06:51, 24 June 2014 (UTC)Support Better name! However it will have to wait because we don't have units yet...--Micru (talk) 14:17, 26 June 2014 (UTC)
@Micru: It sounds like you're just opposing the name. I've changed it. --Jakob (talk) 12:37, 24 June 2014 (UTC)
@Jeblad: In the development plan we have a geo-shape datatype (Wikidata:Development_plan#Geo-shape_datatype). I think it would be best to wait for that datatype. We could then either create this property or see if we can fill the database with high resolution shapes and then calculate values like: area, longest / shortest axis, northernmost point etc... -Tobias1984 (talk) 20:45, 26 October 2014 (UTC)
If the shape is known, then it should be no problem to infer this value, but having an extent of an object does not imply having a shape of the same object. Jeblad (talk) 20:53, 26 October 2014 (UTC)
I think it also depends on the resolution our geo-shapes will have. The calculated length of a lake especially with low-resolution polygons might be in conflict with what our sources say. So we probably need a property like this to input official survey data. -Tobias1984 (talk) 21:01, 26 October 2014 (UTC)
This is often referred to as one dimension i an spatial extent, where the extent itself is either an instance of a class or a typed blank node. Because we probably want to describe this in a simple way we should keep the description "flat". We could use the qualifiers to describe all the values for an "extent", but then we would have nothing for the main snak. Or, we could set it to "no value". That would be weird. Jeblad (talk) 21:16, 26 October 2014 (UTC)
Wait until we have number with dimension datatype. Filceolaire (talk) 21:10, 31 October 2014 (UTC)
I guess this can be interpreted as the same that is described as "length" in Wikidata:Property proposal/Pending/2. It is often called the "major axis length". If we only call it length it will probably not be accurate enough. Imagine a lake with its largest extent east-west and a river flowing in from north and out to south. Then some people will say that the lakes biggest length is east-west (extent) and some north-south (direction of flow). We need something more accurate than this. Jeblad (talk) 13:50, 28 February 2015 (UTC)