FactGrid talk:Buildings data model: Difference between revisions

From FactGrid
Jump to navigation Jump to search
Line 35: Line 35:
See: [[user:Florian Linsel]] [[user:Olaf Simons]]
See: [[user:Florian Linsel]] [[user:Olaf Simons]]
My latest mode was to extract "Streets" out of the location (look here: [https://tinyurl.com/yrd9khyz Locations per Street]). We would have to fix it for Leipzig for around 4000 "addresses".  –-[[User:Laurenz Stapf|Laurenz Stapf]] ([[User talk:Laurenz Stapf|talk]]) 13:34, 7 May 2024 (CEST)
My latest mode was to extract "Streets" out of the location (look here: [https://tinyurl.com/yrd9khyz Locations per Street]). We would have to fix it for Leipzig for around 4000 "addresses".  –-[[User:Laurenz Stapf|Laurenz Stapf]] ([[User talk:Laurenz Stapf|talk]]) 13:34, 7 May 2024 (CEST)
Dear Bruno,
Dear Daniel,
I added an example from the Leipzig-Data [[item:Q482685]], for which we experimented with some more ways to visualize the House on a map.
Even cadastral numberance got a place with address names [[property:P153]] because, like older "sounding" housenames, it's a more static identifier of an House than depending numbering regimes. Because "naming and cadastral numbering" is a static qualifier of an House, not necessarily bound with an street, I prefer to hold the item in the first row,  adding more qualifiers like time space of use etc.
To present the continuity of "place" up to present day, i.e. split and combination of real estates, we didn't have finally decided, depending on the less necessity and uncertainty in the limited sources.––[[User:Laurenz Stapf|Laurenz Stapf]] ([[User talk:Laurenz Stapf|talk]]) 15:35, 7 May 2024 (CEST)

Revision as of 15:35, 7 May 2024

Bruno Belhoste

Discussion moved from User talk:Bruno Belhoste#Houses.

Dear Daniel,

As you know, data modelling is a matter of philosophy. Your data model is nice, but it needs three special new properties. This may make the user's task easier, but it has the disadvantage of multiplying the number of properties. In my opinion, this is not desirable because it is almost impossible to create an ontology of properties with WikiBase. In case you create special properties for addresses, why not to create special properties for everything else, and finally you will end up with the huge bunch of properties of Wikidata: a nightmare.

In the case of addresses, if you have a unique very simple property like P47 for the location of houses, it is sufficient to add the triple : ?street wdt:P2 ? wd:Q147195 to the triple : ?address wdt:P47 ?street to get the street of the address. It is one line more, but one property less, and I think it is preferable.

For the number of the house, I would simply add a qualifier P90 (number as a string) to the statement P47->Qid where Qid is a street and in queries: ?address p:P47 Qid [ps:P47 Qid, pq:P90 ?number] instead of: ?address wdt:P1120 Qid; wdt:P152 ?number.

As I said at the beginning, this is a matter of philosophy. However, there is another objection to your data modelling: there are already many items using the data modelling with P47 (for Paris, Leipzig, Gotha) and it would be reasonable to follow the same pattern for your own project. --Bruno Belhoste (talk) 14:06, 7 May 2024 (CEST)

Dear Bruno, thanks for the reply. I understand your point of view in case of addresses. It is really a matter of philosophy. However, I have also one: hierarchical structure. That means that if we have statement location:quarter, we do not need location:city, because we can make a query. It is one line more in query, but one statement less. I think if we put all (street, quarter, city) to P47 (location), we actually create redundancy. So I think that more properties are preferable to redundancy.
Also, there is quite serious problem with housenumbers (P152 exists for a long time). For example this house had number 56 until 1920, when the Jewish Quarter had status of autonomous municipality. However, when it was merged with the "Christian" town, the houses in the Jewish Quarter had got new numbers (612 in our case). However, I cannot add a qualifier to a qualifier. --Daniel Baránek (talk) 14:36, 7 May 2024 (CEST)

Laurenz Stapf

Copied from User talk:Laurenz Stapf#Houses. --Daniel Baránek (talk) 14:38, 7 May 2024 (CEST)

Dear Daniel, I think, the structure in the Leipzig-Data is even a direct herity of the structure for Paris (item:Q314208). I would be glad with a split. Actually, the established mixed use of property:P47 in our Leipzig-Data could afford an upgrade. Further my dear colleague user:David Löblich had build it for Aschersleben (item:Q497317), with view on the neighborhoods, about a property:P8-workflow, good for easy bottom-up query-pipes. Our student-workshop next month could create some further thoughts about defining neighborhood in Leipzig. Your Properties are looking easy-applicable for that. See: user:Florian Linsel user:Olaf Simons My latest mode was to extract "Streets" out of the location (look here: Locations per Street). We would have to fix it for Leipzig for around 4000 "addresses".  –-Laurenz Stapf (talk) 13:34, 7 May 2024 (CEST)

Dear Bruno, Dear Daniel, I added an example from the Leipzig-Data item:Q482685, for which we experimented with some more ways to visualize the House on a map. Even cadastral numberance got a place with address names property:P153 because, like older "sounding" housenames, it's a more static identifier of an House than depending numbering regimes. Because "naming and cadastral numbering" is a static qualifier of an House, not necessarily bound with an street, I prefer to hold the item in the first row, adding more qualifiers like time space of use etc. To present the continuity of "place" up to present day, i.e. split and combination of real estates, we didn't have finally decided, depending on the less necessity and uncertainty in the limited sources.––Laurenz Stapf (talk) 15:35, 7 May 2024 (CEST)