Item talk:Q10
Jump to navigation
Jump to search
Subclass
@Yurik:: I disagree that Q10 (OSM concept) is a P3 (subclass of) Q10 (OSM concept). It is a P3 (subclass of) (concept), for which we do not have an item in this wiki (yet?). --YjM (talk) 23:11, 19 January 2019 (UTC)
- YjM, true, but i don't think its worth creating - we could just rename OSM concept into a concept - same difference :) I don't think there is a practical reason to establish a complex "proper" hierarchy in OSM data items in the same way we do in Wikidata - rather I would like to concentrate on the OSM goals - structured storage of OSM-related things like keys, values, presets, validation rules, etc. But if you feel very strongly about it, sure, go ahead and create another item. --Yurik (talk) 01:35, 20 January 2019 (UTC)
- @Yurik: I was more thinking about removing this statement, rather then creating top-level items, if you wouldn't mind. I don't really feel comfortable about having cycles of this kind in the ontology... --YjM (talk) 11:14, 20 January 2019 (UTC)
- YjM, the only real reason I had it there is to prevent any type of data validation scripts/queries from showing a warning for Q10. If a novice user adds a new item, they could forget to add instance-of for Q10. This is really not a big deal, so feel free to remove too.
- BTW, on an unrelated note, there is no need to add labels for languages other than English for keys/tags if they are identical to English. See label description. Thx! --Yurik (talk) 23:07, 20 January 2019 (UTC)
- @Yurik: If there is a live use-case for having the data being modeled in this manner, I am ok with it. We will see in the future, if there won't be some semantic reasoners which will die in such cycles. We can re-discuss it then.
- As of the second thing: thanks for pointing to that! I haven't read the Data items page thoroughly and expected the rules to be the same as in Wikidata. --YjM (talk) 13:22, 21 January 2019 (UTC)
- @Yurik: I was more thinking about removing this statement, rather then creating top-level items, if you wouldn't mind. I don't really feel comfortable about having cycles of this kind in the ontology... --YjM (talk) 11:14, 20 January 2019 (UTC)
Notation of the label
@Cisnerosjoven: Hi, I saw your change to the label from "OpenStreetMap concept" to "Open Street Map concept" and want to ask why? I think it was right before because "OpenStreetMap" is a fix term / name / trademark. --Chris2map (talk) 05:46, 22 August 2024 (UTC)
- It looks like a new user’s actions, with other questionable edits. I believe it should be reverted. Bxl-forever (talk) 08:48, 22 August 2024 (UTC)
- Without a doubt. I have changed the label back. Not sure about the relation to Q22085 though. I am not familiar with OpenHistoricalMap so I can't quite tell which of the "concepts" is actually a superclass... --YjM (talk) 11:28, 22 August 2024 (UTC)
OpenHistoricalMap concept
- Thanks for quick reactions and revert of the label! Regarding the OpenHistoricalMap concept I also have to pass. I don't understand the correct relationship either. If they are not the same level, then I would rather see it the other way around, that "OpenHistoricalMap concept" is a subclass of "OpenStreetMap concept", isn't it? @Minh Nguyen: --Chris2map (talk) 16:20, 22 August 2024 (UTC)
- @Chris2map: I figured that every OSM tag is also a valid OHM tag, but there are some OHM tags that don't make any sense in OSM, like type=chronology, the OHM version of start_date=*, eventually a variety of tags about real-world features/languages/religions/cuisines that no longer exist, and whatever OHM is going to do about events. Alternatively, we could model them all as OSM concepts, with a new property to indicate whether the item applies to one project or the other (or, say, OpenGeofiction). But this seemed to be the most straightforward way to avoid having to retag items en masse. If OpenHistoricalMap concept (Q22085) is a subclass of OpenStreetMap concept (Q10), then technically we'd need to make every individual instance of OpenStreetMap concept (Q10) also an instance of OpenHistoricalMap concept (Q22085). – Minh Nguyễn 💬 21:28, 22 August 2024 (UTC)
- @Minh Nguyen: From your description, I conclude that the original hierarchy OpenStreetMap concept (Q10) subclass of (P3) OpenHistoricalMap concept (Q22085) was correct. I am in favor of returning that statement back. Any disagreement? --YjM (talk) 21:41, 22 August 2024 (UTC)
- @Chris2map: I figured that every OSM tag is also a valid OHM tag, but there are some OHM tags that don't make any sense in OSM, like type=chronology, the OHM version of start_date=*, eventually a variety of tags about real-world features/languages/religions/cuisines that no longer exist, and whatever OHM is going to do about events. Alternatively, we could model them all as OSM concepts, with a new property to indicate whether the item applies to one project or the other (or, say, OpenGeofiction). But this seemed to be the most straightforward way to avoid having to retag items en masse. If OpenHistoricalMap concept (Q22085) is a subclass of OpenStreetMap concept (Q10), then technically we'd need to make every individual instance of OpenStreetMap concept (Q10) also an instance of OpenHistoricalMap concept (Q22085). – Minh Nguyễn 💬 21:28, 22 August 2024 (UTC)
- @Chris2map: For now, nothing outside of this namespace directly depends on these two items per se. However, items like OpenHistoricalMap relation type (Q22086) are subclasses of these items. chronology relation (Q22087) should indicate that it's OHM-specific in structured form, besides the human-readable description. Looking ahead, {{Description}} and related templates currently switch on the first part of the page title to determine whether the page describes an OHM-specific concept, but this is fragile and unsuitable for drafts and proposals. Maybe checking for membership in one of these subclasses would be a better alternative. – Minh Nguyễn 💬 15:08, 24 August 2024 (UTC)
- @Minh Nguyen: I see and having an indicator (the data item) that could be checked by software to distinguish an OHM feature is the right thing. But it also means manual work, as every feature has to have a data item. This would then have to be done consistently in drafts and proposals. Since not everyone is convinced by the data items, I am still a little worried and estimate that the probability is currently higher that this distinction (OHM / OSM) could be practically implemented using a parameter in the templates (OpenHistoricalMap=yes/only). – I reverted the removal of the subclass. --Chris2map (talk) 09:18, 25 August 2024 (UTC)
- @Chris2map: For now, nothing outside of this namespace directly depends on these two items per se. However, items like OpenHistoricalMap relation type (Q22086) are subclasses of these items. chronology relation (Q22087) should indicate that it's OHM-specific in structured form, besides the human-readable description. Looking ahead, {{Description}} and related templates currently switch on the first part of the page title to determine whether the page describes an OHM-specific concept, but this is fragile and unsuitable for drafts and proposals. Maybe checking for membership in one of these subclasses would be a better alternative. – Minh Nguyễn 💬 15:08, 24 August 2024 (UTC)
- @Chris2map: Thanks! As it happens, we now have a need for this distinction in Pt:OpenHistoricalMap/Tags/Key/license. Since "Pt:" isn't a real namespace, {{Description}} can't detect it's for OpenHistoricalMap based on the root page name alone. As a workaround, I added |project = to {{Description}}, which these translated pages can set manually. – Minh Nguyễn 💬 18:40, 27 August 2024 (UTC)