Author Topic: Resolving semantic issue with the "part of" property  (Read 3718 times)

Indirik

  • Exalted Emperor
  • ******
  • Posts: 10849
  • No pressure, no diamonds.
    • View Profile
Given the issues in trying to get templates like "regions of" and Masdus'  "User:Masdus/regionlistbox" to properly handle duchies and imperial regions, I think we need to redo the way that we are handling regions and realms. Specifically, the [[part of:: ]] property really cannot handle the overloading to indicate both being part of a realm and a duchy, especially if both have the same name.

I don't see a solution to the issue so long as we use [[part of:: ]] to handle both the region<>duchy relationship and the region<>realm relationship. A separate issue is the insistence to not use something like the "Imperial" duchy.  I know that "Imperial" duchy is incorrect in a purist sense, but I can't see any other way to do it. It is impossible to search for the *lack* of a property. Also, we have no way to determine whether the [[part of::Perdan]] refers to the duchy of Perdan or the realm of Perdan.

I think that the only true way to solve this is to do two things:

First, I think we need to actualy specify a duchy for /every/ region. Even if the duchy is set as "none", it gives us something to search for, that we can use to detect imperial regions. This would let us find the imperial regions in a realm. What this will *not* do is solve the problem of differentiating whether [[part of::Perdan]] means that a region is part of the /realm/ of Perdan or the /duchy/ of Perdan. {{#ask:[[part of::Perdan]]}} returns every region that is in the realm of Perdan. How do I tell it I only want things in the duchy of Perdan? Doubly bad if the realm does not own its namesake city. So, by itself this will not solve all of our problems.

Second, I think we need to differentiate between the region<>duchy relationship and the region<>realm relationship. One possibility is to create a new property: [[duchy of:: ]]. This will let us differentiate between these two relationships. [[duchy of::Perdan]] will therefore only list regions that are part of the duchy of Perdan, and not just part of the /realm/ of Perdan. However, this will not let us find regions that are not part of any duchy at all. [[duchy of::!+]] is still an invalid query, and will return [[duchy of::+]], which is every region with the "duchy of" property set. So, by itself this will not solve all of our problems.

So I think we need to do both of these things in order to be able to completely solve our problems with the Imperial duchy and identical duchy/realm names.

Now, we may be able to avoid using [[duchy of:: ]] if we change [[part of::]] to a Record type Property. These used to be called multi-valued properties. They would solve the problem with common duchy/realm names. We would do something like: [[has fields:: Page; Page]], where the first Page is the realm and the second Page is the duchy. But this still wouldn't let us find regions that have no duchy. {{#ask: [[part of::Perdan]]}} returns all regions in the realm of Perdan, ignoring the duchy part of the property. You could find everything associated with the duchy of Perdan by using: {{#ask: [[part of::?; Perdan]]}}. But {{#ask: [[part of::Perdan; !+]]}} is still an invalid query, because you cannot search for the lack of a property.

I *think* that switching [[part of:: ]] to a Record type property with two fields, and then specifying "none" or "Imperial" for the duchy would do what we need.

I'd like to finally resolve this issue. The way we have things now, they just don't work. And we can't fully enforce semantic use if the semantics are broken.
If at first you don't succeed, don't take up skydiving.

Tom

  • BM Dev Team
  • Exalted Emperor
  • *
  • Posts: 8228
    • View Profile
    • BattleMaster
I agree, but - before we invest too much work into this, please wait for current developments on the region/duchy system the Dev Team is working on.

De-Legro

  • Honourable King
  • *****
  • Posts: 3838
    • View Profile
I though my region list box handles Duchies pretty well, though yes it has issues with realms named after the capital. I haven't really looked at how to handle imperial regions though. The bigger problem for me about rolling the thing out is that semantic data still isn't updated without a page save. One way around it that might not be as big a resource drain as the standard semantic update script, would be to produce a couple of pages that import all the external data about regions etc, and then have a script update these pages at whatever interval.

If you look at the Arcaean region pages, you can see Part of is already holding multiple entries, so I'm not 100% on what the advantage of moving to record type property, unless this type would make it easier to figure out which on the entries is associated with a level of realm hierarchy?
« Last Edit: March 03, 2011, 12:24:33 AM by De-Legro »
Previously of the De-Legro Family
Now of representation unknown.

Indirik

  • Exalted Emperor
  • ******
  • Posts: 10849
  • No pressure, no diamonds.
    • View Profile
I though my region list box handles Duchies pretty well, though yes it has issues with realms named after the capital. I haven't really looked at how to handle imperial regions though. The bigger problem for me about rolling the thing out is that semantic data still isn't updated without a page save. One way around it that might not be as big a resource drain as the standard semantic update script, would be to produce a couple of pages that import all the external data about regions etc, and then have a script update these pages at whatever interval.

The need to save a page to refresh the semantic data is unfortunate, but can be worked around. I run an admin script on the wiki every other day or so that refreshes the semantic data. This means that the semantic data could be as much as two days old. While that is not ideal, it means that pages that use semantic lists will be updated on a regular basis without manual intervention.

I don't think the idea of one big page with all the external semantic data would work at all. The context of what page the data appears on is an inherent property of the data. If you created a page [[ImportOne]], there would be no way on that page to say that [[Brive]] is part of [[Perdan]].

Quote
If you look at the Arcaean region pages, you can see Part of is already holding multiple entries, so I'm not 100% on what the advantage of moving to record type property, unless this type would make it easier to figure out which on the entries is associated with a level of realm hierarchy?

The idea is to specify what that region is a part of. For example, right now on EI, Fontan city is not part of the realm of Fontan, it's part of Sirion. So if you put [[part of ::Fontan]] on a region page, are you saying that it's part of the realm of Fontan or the duchy of Fontan? And if you want to see what regions are in the duchy of Fontan, you'll actually get a list of all the regions that are also in the realm of Fontan.

The idea of the Record property is to add context to the the "part of", while still allowing us to resort to having a separate "duchy of" propertry. It would denote what that relationship is: region>realm or region>duchy.
If at first you don't succeed, don't take up skydiving.