Guild Wars 2 Wiki talk:Semantic MediaWiki/Locations
Relyk originally had separate properties to identify the area, zone, and region that contain a location. This is unnecessary since we can compute property chains, i.e. a map point will list the area it is located in, then the area lists which zone it is in, and the zone lists which region it is in. From the map point, we can follow the property chain all the way up within a semantic query and output the full hierarchy. —Dr Ishmael 06:30, 25 November 2012 (UTC)
- That's what I wanted, but I didn't know the implementation. This will use [[Property:Subproperty of]] correct?--Relyk 20:16, 3 December 2012 (UTC)
- No. See here - the last example in that section is what I'm talking about, except that in our case it would be multiple instances of the same property instead of different properties. E.g.
[[Category:Jumping puzzles]] [[Is located in.Is located in::Maguuma Jungle]]
- —Dr Ishmael 20:31, 3 December 2012 (UTC)
- Ah coding it that way makes sense since its the same as a node tree. I was also thinking about the properties of the zone and areas themselves. If we ask a area for its hearts, it'll return the number of hearts. If we ask the zone for its number of hearts, it would be the sum of the hearts for all the areas. I thought subproperty allows that kind of implementation.--Relyk 21:32, 3 December 2012 (UTC)
- —Dr Ishmael 20:31, 3 December 2012 (UTC)
- Subproperties are for when the properties themselves have a hierarchy. One example is familial relationships: Parent of would have the subproperties Father of and Mother of. You want to keep the distinction between mothers and fathers, but you also want the ability to query both mothers and fathers at the same time. Another one is specificity: Capital of would be a subproperty of Located in, since any capital city is by definition located within the state it serves as capital.
- In our case, I don't think we have either kind of distinction. We just have things that are located within other things. —Dr Ishmael 22:27, 3 December 2012 (UTC)
- I see. If we want to query for points of interest in a certain zone, {{#ask:[[Has location type::Point of interest]] [[Is located in::Magumma Jungle]]}} should work properly?
Or does it have to be [[Is located in.Is located in::Magumma Jungle]]?Can't use subqueries.--Relyk 22:56, 3 December 2012 (UTC)
- I see. If we want to query for points of interest in a certain zone, {{#ask:[[Has location type::Point of interest]] [[Is located in::Magumma Jungle]]}} should work properly?
- Yes, for PoIs in a zone, since we define that the PoIs themselves are located in an area, and areas are located in zones:
[[Has location type::Point of interest]][[Is located in.Is located in::<zone name>]]
(you have a region name). - What do you mean, can't use subqueries?
{{#ask:[[Is in trait line.Is for profession::Warrior]]}}
works fine to list all warrior traits. —Dr Ishmael 23:22, 3 December 2012 (UTC)- It was noted on smw, that must be referring to using subqueries to retrieve multiple properties at once.--Relyk 03:31, 4 December 2012 (UTC)
- Yes, for PoIs in a zone, since we define that the PoIs themselves are located in an area, and areas are located in zones:
Counters[edit]
The waypoint/vista internal objects could hold a value that tracks the number of internal objects of that type on the area page. We will set the property on both areas and zones.--Relyk ~ talk > 02:40, 16 February 2013 (UTC)
Footnotes[edit]
- Renown hearts, skill challenges, and points of interest can be counted by querying with the sum format from Semantic Result Formats:
that sounds unnecessarily awkward to query. I've added a few properties to try and get Map completion/table semanticised (currently at [[User:Chieftain Alex/sandbox9]]) - the technique in the footnotes looks inefficient if its creating 6 queries for each row (in the case of this template)
=== [[Property:Has points of interest]] === === [[Property:Has renown hearts]] === === [[Property:Has skill challenges]] === === [[Property:Has vistas]] === === [[Property:Has waypoints]] === ; Purpose: Identifies the number of [[renown heart]]s/[[skill challenge]]s/[[vista]]s/[[waypoint]]s/[[waypoint]]s in the [[location]]. ; Applies to: <s>Areas</s> and explorable zones ; Has type: Number
Additionally, I believe that it would be useful to have a property to record whether an area counts towards map completion or not. -Chieftain Alex 11:57, 21 December 2013 (UTC)
- It's a very simple query: {{#ask:[[Located in.Located in::<zone>]][[Has location type::Waypoint]]|format=sum}}. Wouldn't work for skill challenges since we don't have a single property to id a skill challenge. Not sure what you mean by area, map completion only refers to objectives on a map, with all the maps beings zones except Chantry of Secrets.--Relyk ~ talk < 13:16, 21 December 2013 (UTC)
- Yes its a simple inline query, but how would you be doing that in a single query for every waypoint entry in the table? -Chieftain Alex 13:37, 21 December 2013 (UTC)
- I don't think that we're on the same wavelength here. Are you suggesting that we do:
{{map completion table row|Explorable zone name1}} {{map completion table row|Explorable zone name2}} {{map completion table row|Explorable zone name3}} where each row is made of 5 queries; {{#ask: .... number of hearts | format = sum }} {{#ask: .... number of skill challenges | format = sum }} {{#ask: .... number of vistas | format = sum }} {{#ask: .... number of points of interest | format = sum }} {{#ask: .... number of waypoints | format = sum }} and there are 39 rows, so 195 queries. which is a hell of a lot..
- rather than one #ask statement to pull most of the data at once + another 5 queries at the bottom to pull the total row -Chieftain Alex 14:31, 21 December 2013 (UTC)
- The way Alex was going with area infobox would have been my approach. Store the values explicitly for areas, then sum them up to store values for zones, then query the zone's data for the table. What exactly was the problem you ran into with that? —Dr Ishmael 17:47, 21 December 2013 (UTC)
- Well I saw the footnotes section right after creating the properties, so I thought that I might try and explain why I went and implemented them on the talk page. Other than filtering the results for the ones I want, I've not had any problems yet.
- There is a bit of a conversation over at [[User talk:Chieftain Alex/sandbox9]] (my bad as usual having wiki discussions on random sandbox talk pages). To summarise that page, Property:Has map objectives (boolean) has been proposed to annotate in SMW whether a zone contributes towards the map completion or not. How we apply that property is open to discussion, relyk thinks specify a parameter if no, and I thought some complex switch statement with a parameter as a possible override.
- I don't know exactly which pages we want to annotate with the properties outlined above yet, as we currently specify the amounts manually on both the zone and area pages... I think that only the lowest level pages should be annotated (mostly areas, but there are a few pages which aren't areas, such as Chantry of Secrets), and all the pages which are parents of those should be SMW'd instead imo. -Chieftain Alex 18:17, 21 December 2013 (UTC)
(Reset indent) I've got a proposal in [[User:Chieftain_Alex/sandbox8]] that I think is ready to go. (it has the zero effort switch statements in atm to determine map completion contribution - could replace these if it works out) -Chieftain Alex 22:34, 23 December 2013 (UTC)
- I've had a bit more of a think about this. On pages such as Kryta, do we record the total number of poi/wp/vistas/hearts/challenges based on the number that contribute, or is it based on the total number of each thing that contributes towards map completion (i.e. does the count at the top of Kryta include dungeon POIs etc?) The reason I ask is because the way I've currently got it, Kryta will add up all the zones within irregardless of whether they contribute to the map completion objectivesor not, so it will include Southsun Cove + Caudecus's Manor. -Chieftain Alex 09:22, 24 December 2013 (UTC)
- Region infoboxes should only convey the numbers required for map completion. —Dr Ishmael 13:38, 24 December 2013 (UTC)