Implement internal references between attribute names in different OC nodes

[GoogleCodeExporter]

Attributes are very important to support.

Original issue reported on code.google.com by o.di...@arcor.de on 30 Aug 2011 at 11:27

• Blocking: #190

[GoogleCodeExporter]

You're right. Groundspeak also has shitty attributes too. ;) Still,
"Bikes allowed" (or even "Horses allowed") targets a MUCH larger
audience than, for example "Public phone nearby" or "First aid
available".

Perhaps, the best way to verify which attributes are "the good ones" 
is to check which are used *for searching* most often. (Such stats 
could be computed both by OKAPI and OC search pages.)

> Attributes serve two different purposes:

> - searching / selecting caches
> - replacing parts of the text description by handy and faster-to-grab icons

> eliminating attributes means eliminating parts of the cache description,
> which I don't think is a good idea.

The first purpose is clear. The second one is a bit weird, but I
agree, that we cannot simply remove them.

> But I think it would be a good idea to distinguish between "searchable"
> and "not searchable" attributes.

How about marking some attributes are "very popular for searching"?
This will let the developers show the popular ones first (+ a checkbox
"show all attributes").

Ad. – - ok. In Poland programmers usually try to stay within the 
latin2 encoding, but in might be a local "custom".

>> <groundspeak id="15" inc="true" name="Available during winter" />
>> I think the opposite attribute would be handy ("not recommended in winter").
>
> Both make sense.

> Therefore we have complementary attributes for the time and
> seasonal things at OC.de, just the winter complement is missing (see issue 70 
#34).

I will make a note and perhaps will add it later.

> Generally, there is no clear distinction between what is a "Cache
> type" and what is an "attribute". You can define "needs
> tree-climbing" as an attribute, or you can define "tree-climbing
> caches" as a type. (...) What about a webcam cache which needs a
> quiz to be solved first? (...) If you have another idea how to solve
> this without redesiging the whole "cache type" system. please let me
> know. :-)

We could reduce the number of cache types in OKAPI, i.e. replace the
"webcam" caches with "traditional + webcam attribute". This can be
done dynamically, without database modifications. But I'm not sure if 
the users will be happy about such changes.

>>> (oc.de attribute 57)
>> I don't understand this. This seems to be a cache type, not an attribute?
>
> (...) this is what the attribute was made for: unconventional
> variants of the usual cache types. It says: Hello, I am no ordinary
> cache!

In Poland, almost half of the "traditional" caches are not ordinary. 
But we spot them by their rating, not the owner's opinion ;) That's 
why I wouldn't use such atrtibutes for searching, etc.

Original comment by rygielski on 30 Mar 2013 at 7:54

[GoogleCodeExporter]

Original comment by rygielski on 30 Mar 2013 at 10:26

[GoogleCodeExporter]

> Perhaps, the best way to verify which attributes are "the good ones" 
> is to check which are used *for searching* most often.

I will analyse our web server logs on this; they date back about a month. 
Fortunately, attributes are passed as GET arguments. I suspect that attributes 
are rarely used at all for searching.

> The second one is a bit weird, but I agree, that we cannot simply remove them.

It's like a checklist: If there were less attributes, the owners would add less 
information to their listings. I really like to browse through the attribute 
list and set each one which is applicable for my new caches. :-) Germans LOVE 
categorizing things. The English Wikipedia's category system is chaos; the 
German's is organized like a military company.

> We could reduce the number of cache types in OKAPI

Cache types are a high-profile decision at OC.de and must be discussed in and 
approved by the team; I would not like the OKAPI project to bypass this. 
Discarding Webcam cache type is definitively no option, while discarding the 
Webcam *attribute* on OKAPI won't hurt: There are only three of these "hybrid 
webcam caches" out there, compared to 240 ordinary webcam caches. The "quiz" 
attribute, on the other hand, is in use for hundreds of non-quiz-type caches.

There are two OC.de cache types that have been questioned: The "Drive-in Cache" 
and the "Math/Physics" cache. I could ask our team if we can strip them from 
OKAPI and replace by Traditional + Parking nearby and Quiz + Arithmetical 
problem.

A new cache type "Bonus" has been discussed, but it might be alternatively 
marked by a new precondition attribute "needs another cache to be found". This 
is low-prio.

Generally, it looks to me like OC.pl has another community than OC.de. OC.de is 
a niche project, just 10% in size of German GC.com and ~20% of average user 
activity, and it has another emphasis. More individualists, people who are 
pissed off by reviewing and who don't care about statistics or the averaging 
results of voting systems (=> we don't have review, no voting and only basic 
statistics). One of my top goals for OC.de development is to add OC-only 
features which make it even more special and distinguishable from GC - I think 
this is the only way to have this relatively small site be successful in 
competition with "big brother" GC. (small = ~10.000 active users and 10.000 
page visits per day).

Having said this: I agree that presenting a subset of attributes to the user 
for searching makes sense - OC.de already has this feature on the search page 
and in the map filter settings; it's selected by the field 
cache_attrib.search_default. But I don't feel comfortable with selecting the 
attributes by "mostly used" instead of "makes sense".

Original comment by following09 on 30 Mar 2013 at 12:16

[GoogleCodeExporter]

Example: The np-season attribute is rarely used, but is important for 
"political reasons" as we want to support nature protection.

The "24/7" attrib is very common, but it does not make sense to search for it. 
Instead, the user wants to know which caches can be made by day / by night, 
which can be internally mapped to 
-DAY: ('24/7' or 'only by day') and not 'recommended at night'
-NIGHT: not 'only by day' or 'nightcache' or 'recommended at night'

Original comment by following09 on 30 Mar 2013 at 1:24

[GoogleCodeExporter]

> Cache types are a high-profile decision at OC.de and must be
> discussed in and approved by the team; I would not like the OKAPI
> project to bypass this.

Okay. That was just a notion. I also think that this should be handled
directly in the database, rather than by dynamic replacement in OKAPI.

> A new cache type "Bonus" has been discussed, but it might be
> alternatively marked by a new precondition attribute "needs another
> cache to be found". This is low-prio.

I am a strong opposer of additional cache types (if it was up to me,
there would be 4 only, all the rest would be described by attributes),
but I won't fight over it - it's a lost cause. ;)

> Generally, it looks to me like OC.pl has another community than
> OC.de.

I think OC is more popular in Poland than GC is! Take a glance at the
activity in our forum and compare it with yours - there's a huge
difference.

> agree that presenting a subset of attributes to the user for
> searching makes sense (...) But I don't feel comfortable with
> selecting the attributes by "mostly used" instead of "makes sense".

How about this:

We will add the "promote" attribute to the <opencaching> element (but
not the <attr> element). Later, perhaps, I will also expose the usage
stats via the methods. We will let the consumers decide which
attributes they show first and how they group and order them. That's a
little more difficult, but it seems fair to all parties.

Original comment by rygielski on 30 Mar 2013 at 3:58

[GoogleCodeExporter]

Consumers always have the choice how to group attributes and what they show 
first or show at all - they may just ignore an OKAPI grouping scheme or a field 
like 'usage' with the values:

0 = this attribute is not recommended as search option
1 = this attribute is considered as useful but not important as search option
2 = this attribute is recommended as search option

From OC point of view I see only benefits and no drawbacks of including such 
information, except that it consumes development ressources. Surely it is not 
high-prio and I can well live without it, if OKAPI at least outputs attributes 
in an order like the one I introduced into attributes.xml: Many clients will 
just output attributes ungrouped in the order OKAPI delivers it, and having no 
order will result in a mess.

Original comment by following09 on 30 Mar 2013 at 8:28

Attachments:

• gsak-orders-attribs-by-gs-id.PNG

[GoogleCodeExporter]

Thanks for adding the de-categories to the attribute definitions!

My proposal regarding 'seach usage' is low-prio and not relevant at the moment; 
I will first have to clean up the OC.de search function before it would make 
sense to add this to OKAPI.

Original comment by following09 on 1 Apr 2013 at 12:43

[GoogleCodeExporter]

It is hard to design this properly. Currently I am struggling with two things:

1. Category relationship: http://i.imgur.com/Uy08rgV.png

Should we make it "optional many-to-many" (0..N - 0..N) or "required 
one-to-many" (1 -- 0..N)? This first choice would allow us to create an 
unlimited number of categories (every OC node could define their own). The 
second choice is more explicit (good) for the external app developers, but it 
would require each node to make sacrifices, and we would have to argue 
frequently. That's why I opt for the first solution.

2. Attribute ID format

It is currently a string, but I am strongly considering changing it into an 
integer. String IDs will generate the same kind of conflicts between nodes as 
the ones above.

For example, OCPL may decide to drop the age restriction from the "children6" 
attribute - instead they will say "it's okay for small children". They will 
feel the need to change the id too (e.g. "small_children"). In case of 
integers, such problems will not occur.

Original comment by rygielski on 1 Apr 2013 at 9:08

[GoogleCodeExporter]

ad 1:
I also have been thinking about this yesterday. Chosing the simpler solution 
would encourage more application developers to support it, therefore I tend 
towards "required one-to-many". But I have no strong feelings about this and 
can live with either solution.

Does "optional many-to-many" mean that multiple categories of the same fork can 
be set for *one* attribute? That would make client implementation even more 
complicated, though it would make sense on some attributes.

> In case of integers, such problems will not occur.

The problems will stay because of attribute names and descriptions, which are 
shared by all nodes - especially the English description. We already have a 
conflict e.g. at the 24/7 attribute, which is just '24' at OCDE. I am going to 
adopt the PL definition here because it makes more sense, but this won't be so 
easy in all cases.

So definition conflicts are independent from the ID format and need not to be 
considered for that. We have to agree on each attribute definition which is 
shared between nodes, or split up attributes if that is impossible. This even 
has a benefit: It urges nodes to match their attribute definitions, which will 
be useful if nodes are interconnected some time and share a global cache 
database.

Original comment by following09 on 1 Apr 2013 at 11:13

[GoogleCodeExporter]

(But ID numbers have another advantage: The attribute definition may be 
changed/adjusted without becoming incompatible with the ID name. This is a 
strong argument for numbers.)

Original comment by following09 on 1 Apr 2013 at 11:17

[GoogleCodeExporter]

"required one-to-many" also would better support a future database integration 
of all nodes - the other option would get really weird then: When I have e.g. 
all OC.de and OC.pl caches available at OC.de, there would be two concurring 
grouping schemes within the same cache database.

Olivers intention with this issue was exatly the opposite: Matching the forks' 
attributes as preparation for a later database integration. But I can 
understand if you say: That's not my business - the *nodes* have to do their 
homework and agree on attribute groups. And database consolidation is far in 
the future or may not happen at all.

Original comment by following09 on 1 Apr 2013 at 11:29

[GoogleCodeExporter]

> the 24/7 attribute, which is just '24' at OCDE

Oops, no. We have a 24/7 icon and just the description is unclear.

Original comment by following09 on 1 Apr 2013 at 11:45

[GoogleCodeExporter]

> Does "optional many-to-many" mean that multiple categories of the
> same fork can be set for *one* attribute?

I'm not sure. I don't like it either. Perhaps it's better to simply
NOT implement it just now. Maybe we'll find a better option given some
time? Please note, that currently there are NO categories *at all* in
OCPL branch (they were not implemented).

>> In case of integers, such problems will not occur.
>
> The problems will stay because of attribute names and descriptions,
> which are shared by all nodes - especially the English description.

True. However, I assume that meanings will mutate only slightly, so
they will still match the previous names, more or less.

> (But ID numbers have another advantage: The attribute definition
> may be changed/adjusted without becoming incompatible with the ID
> name. This is a strong argument for numbers.)

Exactly.

BTW, it's not necessary for the names to be a literal translation for
every language, as long as the meaning stays the same. For example,
English name "Magnetic cache" has the "Przyczepiona magnesem" name in
Polish, which literally means "Attached with a magnet". Similarilly,
your "24" has the same meaning as "24/7" or "Available at all times"
etc.

Original comment by rygielski on 2 Apr 2013 at 7:29

[GoogleCodeExporter]

Original comment by rygielski on 4 Apr 2013 at 2:36

• Now blocking: #190

[GoogleCodeExporter]

Instead of assigning attributes to site URLs in attributes.xml, it might be 
better to use node IDs.

Original comment by following09 on 6 Apr 2013 at 7:54

[GoogleCodeExporter]

I have looked at one of our webserver logfiles, regarding attribute-searching. 
Yesterday, there where about 8000 search requests which look like manual 
searches through www.opencaching.de/search.php. 500 of them selected one or 
more attributes. This is more than I thought.

Then I analyzed the log files of the last last days for the most-wanted 
attributes (only "positive search"). Here is the OC.de attrib-search hitlist:

334x Suited for children
222x Public transportation  
137x Near the parking area ("Drive-In")
134x Parking area nearby
126x Point of interest
123x Long walk
108x Swamp or marsh
97x Only at night
85x Only loggable at Opencaching
74x Some climbing (no gear needed)
68x Hilly area
46x Climbing gear
38x Letterbox
37x Available 24 hours
37x All seasons
36x Without GPS
34x Puzzle / Mystery
31x Moving target
31x Compass
31x Flashlight
22x Snow-proof hiding place

It puzzles me why so many people search for Swamp/Marsh - this was frequently 
requestend on all three days. Looks like there are lots of swamp-lovers out 
there. :-)

Original comment by following09 on 12 Apr 2013 at 12:57

[GoogleCodeExporter]

"last last" -> "last three", i.e. April 9-11

Original comment by following09 on 12 Apr 2013 at 12:58

[GoogleCodeExporter]

Nice stats :) Is it possible to extract the same for "negative search"?

Original comment by rygielski on 12 Apr 2013 at 7:57

[GoogleCodeExporter]

I have done a more thorough analysis now over the past 15 days, for both 
options. There were ~150.000 probably-manual search requests, ~5000 with 
attribs (only half the percentage of the 500/8000 above - probably I did some 
logical error somewhere, but I have no idea where).

Please note that there is a preselected set of attributes on 
opencaching.de/search.php, while the user must press "show all" to see the rest.

count [internal-ID] name

"positive search":
1162 [59] Suited for children
913 [1] Only at night
797 [19] Public transportation
602 [18] Parking area nearby
562 [6] Only loggable at Opencaching
516 [24] Near the parking area
445 [30] Point of interest
427 [25] Long walk
229 [35] Without GPS (letterboxes, cistes, compass juggling ...)
222 [27] Hilly area
203 [26] Swamp or marsh
186 [28] Some climbing (no gear needed)
145 [49] Climbing gear
144 [44] Snow-proof hiding place
136 [8] Letterbox (needs stamp)
108 [55] Puzzle / Mystery
87 [50] Cave equipment
71 [38] Available 24 hours
44 [48] Flashlight
40 [56] Arithmetical problem
40 [42] All seasons
34 [47] Compass
31 [31] Moving target
29 [34] In the water
29 [54] Investigation
15 [43] Breeding season / protected nature
14 [57] Other cache type
11 [36] Access or parking fee
10 [9] Dangerous area
9 [15] Abandoned mines
9 [10] Active railway nearby
6 [11] Cliff / Rocks
6 [12] Hunting
6 [16] Poisonous plants
6 [14] Ticks
6 [17] Dangerous animals
6 [13] Thorns
5 [51] Diving equipment
3 [41] Not at high water level
3 [21] Public restrooms nearby
3 [20] Drinking water nearby
2 [40] by day only

"negative search":
535 [51] Diving equipment
476 [49] Climbing gear
370 [1] Only at night
339 [34] In the water
329 [50] Cave equipment
313 [6] Only loggable at Opencaching
235 [36] Access or parking fee
230 [28] Some climbing (no gear needed)
221 [24] Near the parking area
159 [54] Investigation
158 [26] Swamp or marsh
114 [8] Letterbox (needs stamp)
111 [18] Parking area nearby
81 [25] Long walk
71 [19] Public transportation
71 [35] Without GPS (letterboxes, cistes, compass juggling ...)
51 [56] Arithmetical problem
46 [59] Suited for children
43 [44] Snow-proof hiding place
37 [27] Hilly area
24 [55] Puzzle / Mystery
23 [17] Dangerous animals
23 [11] Cliff / Rocks
21 [12] Hunting
20 [10] Active railway nearby
18 [15] Abandoned mines
16 [13] Thorns
16 [14] Ticks
16 [16] Poisonous plants
15 [33] Wihin enclosed rooms (caves, buildings etc.)
7 [43] Breeding season / protected nature
6 [30] Point of interest
5 [9] Dangerous area
5 [29] Swimming required
3 [46] Special equipment
3 [60] Only available during specified seasons
3 [58] Ask owner for start conditions
3 [52] Watercraft
3 [40] by day only
3 [37] Overnight stay necessary
3 [23] First aid available
3 [39] Only available at specified times
3 [22] Public phone nearby
3 [32] Webcam
3 [31] Moving target
2 [41] Not at high water level

Only a few requests excluded "breading season", which has started in April - 
even less then *including* it. :(

Original comment by following09 on 13 Apr 2013 at 2:52

[GoogleCodeExporter]

"breading season" seems a poor name for a cache attribute. It is not specific 
enough. Compare:

I want to find caches which...
- Toolsneeded: UNchecking climbing hear - easy! "1. Do not require climbing 
hear"
- Infrastucture: checking parking area nearby - easy! "2. Have parking area 
nearby",
- Seasonal: checking breeding season - huh? "3. Cool to find during the 
breeding season?" - WRONG

You have similar problems with many other attributes. The categories and user 
interface used by geocaching.com seems much clearer.

Original comment by rygielski on 14 Apr 2013 at 10:49

[GoogleCodeExporter]

I mean that GC's cactegory+attribute pairs are much better defined by their 
name:

http://www.geocaching.com/about/icons.aspx
http://i.imgur.com/iB4y1PP.png

When a user checks or unchecks an attribute he/she wants to know exactly what 
it means. GC's categories define the meaning "something is required or not", 
"something is present or not present". Whereas many of OCDE's categories do not.

Original comment by rygielski on 14 Apr 2013 at 11:04

[GoogleCodeExporter]

Ack, the attibute usage interface at OC.de is flawed and needs improvments. See 
#49:

> (Actually, OC.de allows all those kind of nonsense searches. It is somewhere 
medium-prio on my todo list to fix this).

Original comment by following09 on 14 Apr 2013 at 11:49

[GoogleCodeExporter]

#44:
> the current OC.de grouping scheme, which is suboptimal

#57:
> I will first have to clean up the OC.de search function before it would make 
sense to add this to OKAPI.

Original comment by following09 on 14 Apr 2013 at 11:51

[GoogleCodeExporter]

> "breading season" seems a poor name for a cache attribute. It is not specific 
enough.

The breading season (http://de.wikipedia.org/wiki/Brut-_und_Setzzeit) is 
defined in German nature protection law, so that's very specific. For normal 
cache search, only "negative selection" is needed here. But for nature 
protection purposes, it may also be useful to verify e.h. how many of the 
caches in a sensible area are marked with this attribute.

Supporting nature protection is high prio for all Geocaching sites in Germany. 
There are lots of conflicts between the geocaching community and nature 
protection organizations, and in more and more areas Geocaching is completely 
prohibited due to nature protection issues. (Exposing NP area information 
through the geocaches method is an issue here.)

Original comment by following09 on 14 Apr 2013 at 12:30

[GoogleCodeExporter]

You misunderstood me. I *don't* think that's a "poor attribute", only a "poor 
name for an attribute". It is more related to the UI than funtionality.

Original comment by rygielski on 14 Apr 2013 at 12:55

[GoogleCodeExporter]

"Breeding season" ist just short for "Do not search during breeding season", 
like "Compass" is short for "You need a compass to find the cache". On OC.de, 
these attrib names are never displayed for themselves, but always as a headline 
for the complete attrib descriptions, therefore they need not to explain the 
whole thing.

The icons are even shorter and reduce it to a minimum, but again: If the user 
selects an attrbute on OC.de, he will always be forced to see the whole 
description (except if JavaScript is disabled, which is very rare).

As we cannot control (but only recommend) how other applications handle this, I 
agree that the OKAPI attribute names need to be more carefully designed.

Original comment by following09 on 14 Apr 2013 at 1:16

[GoogleCodeExporter]

On the other hand, I think that all rarely used attributes may be removed. No 
one will miss them. If I had some more time, I would make similar stats and 
remove most of the OCPL attributes.

I think we should also prepare the external developers for such scenario (that 
some attributes may get removed over time).

Original comment by rygielski on 14 Apr 2013 at 1:22

[GoogleCodeExporter]

> On OC.de, these attrib names are never displayed for themselves, but always 
as a headline for the complete attrib descriptions, therefore they need not to 
explain the whole thing.

I saw your UI, but still I didn't understand the meaning. Should I "check" or 
"uncheck" "breeding" if I don't want to disturb the birds? It is unclear, even 
after reading the description.

Original comment by rygielski on 14 Apr 2013 at 1:24

[GoogleCodeExporter]

This issue was updated by revision r726.

An idea which would make (if completed) the attribute names somewhat more 
understandable.

Original comment by rygielski on 14 Apr 2013 at 1:47

[GoogleCodeExporter]

Sure. That's one of several flaws of the attrib search function on OC.de. 
Improving attrib search is one of the 150 items on our todo list.

> I think that all rarely used attributes may be removed. No one will miss 
them. 

As I explained in #49 and #53, I disagree on this. A rarely used attribute may 
still make sense, and it may still be necessary to have a complete description 
of a cache.

There are a few attributes which may be discared because they don't make sense 
- e.g. the "poisonous plants" and "dangeours animals" attributes are frequently 
used just for fun just to say "dangerous WHAT?". Or the "bicycle" and 
"wheelchair" attribs at OCPL - I explained above why these are bogus. Actually, 
most of these bogus attributes have their origin at GC.com ...

Generally, I still prefer this:

1. Expose all local attributes through OKAPI.
2. Define a four-state (or two boolean) "search recommendation" flag for all 
attributes, which say if they are make sense for positive or negative search.

I think that (2) can be objectively done for nearly all attribs. E.g. it does 
not make sense to search for the "danger" attribs at all, as I explained above, 
and it does not make sense to search for "uninteresting places" etc.

Original comment by following09 on 14 Apr 2013 at 1:48

[GoogleCodeExporter]

> An idea which would make (if completed) the attribute names somewhat more 
understandable.

Wont't this introduce the fundamental flaws of the GC attribute system into 
OKAPI? E.g. GC allows lots of contradicting attributes: you may combine "night 
cache" with NOT "recommended at night", "significant hike" with NOT "long walk" 
etc. Even if you disallow this in the user interface - wich GC does not (!) -, 
it is present in the data format and all kind of old data out there (like GPX 
files) and need to be handled by applications. If OKAPI allows posting listings 
some time in the future, it will have to handle contradicting attribs set by 
the users ...

Actually, there are not only two-state options but also three- or more-state. 
E.g. short walk / medium walk / long walk. Or no climbing / easy climbing / 
difficult climbing. You would you fit that into a two-state system?

Original comment by following09 on 14 Apr 2013 at 2:05

[GoogleCodeExporter]

near parking area / short walk / medium walk / lonk walk - that's four-state

Original comment by following09 on 14 Apr 2013 at 2:08

[GoogleCodeExporter]

I think if the OC attribute system is to be redesigned from one-state to 
multiple-state, this should be done bottom-up, from the OC databases through OC 
websites and then into OKAPI. But actually, I see only very few attributes 
where mutliple states make sense.

For example: "no flashlight required". This is true for >99% of the caches out 
there, therefore nearly noone will set this attribute - it is just implied. But 
if nearly noone sets is, then it is meaningless to search for it. We would need 
to *force* owners to chose a flashlight attrib so that this makes sense - but 
that would be too annoying.

Original comment by following09 on 14 Apr 2013 at 2:39

[GoogleCodeExporter]

The idea behind <form> is purely grammatical. For a set of +attrs and -attrs I 
would like to be able to create a textual representation of what will be 
included and excluded from the result. A hint to appear when the user is 
hovering the mouse over a "checked" or "unchecked" attribute.

In other words, I don't want to introduce anything new.

Original comment by rygielski on 14 Apr 2013 at 3:09

[GoogleCodeExporter]

Ok, now I understand it.

Original comment by following09 on 14 Apr 2013 at 4:01

[GoogleCodeExporter]

The current implementation (r736) allows mapping one internal attribute ID to 
multiple OKAPI attribute IDs. This is powerful and flexible, but it also means 
that OKAPI attribute data cannot be mapped back to local attributes.

Example:

Local ID 1 <-> OKAPI IDs A10 and A11.
Local ID 2 <-> OKAPI IDS A11 and A12.

Local attribute 1 -> OKAPI attributes A10/A11 -> local attributes 1 and 2.

So OKAPI gets useless if someone e.g. wants to replicate between OCDE(-like) 
databases, which contain listings and attributes as shown on OC.de. OKAPI 
becomes a one-way system, from local space into OKAPI space without a return 
ticket.

I can live with that, as we already have a proven-stable replication system at 
OC.de (the "XML interface"). Just want to point this out, for the case you did 
not consider it.

Original comment by following09 on 15 Apr 2013 at 9:08

[GoogleCodeExporter]

This also concerns data exchange between *different* database branches like 
OCDE and OCPL. OKAPI will not be usable as basis for an "Opencaching network" 
of interconnected nodes, as attributes can mutate on each network hop. 

Also, it may impact interoperability with other data sources.

Original comment by following09 on 15 Apr 2013 at 10:56

[GoogleCodeExporter]

> Local attribute 1 -> OKAPI attributes A10/A11 -> local attributes 1 and 2.

The correct way to say it would be:

Local attribute 1 -> OKAPI attributes A10/A11 -> local attributes 1 *OR* 2. 
(See the ERD graph from comment 58 - http://i.imgur.com/Uy08rgV.png)

I do not plan on using this many-to-many mapping frequently (I hope we won't 
have to), but it will be much safer if we anticipate this. There are many 
attributes which can be merged into other attributes, etc.

Original comment by rygielski on 16 Apr 2013 at 6:04

[GoogleCodeExporter]

What about tagging one global attribute for each local attribute as the 
"primary" attribute, and adding a field 'primary_attr_ids' to the geocaches 
method? This could be used instead of attr_ids by applications which need to 
match OKAPI data to other OC data sources. This would at least enable OKAPI 
attribute replication beween databases of the same DB branch.

AttrHelper::refresh_from_string could include verifications that exactly one 
primary global attribute is defined for each local attribute.

(Definitions then would be best done the other way round then: Secondary 
attributes are tagged as "secondary", as this is the exceptional case).

Original comment by following09 on 16 Apr 2013 at 10:42

[GoogleCodeExporter]

One more suggestion regarding the services/attrs/allmeta docs:

It should be stated that the meaning of an OKAPI attribute IDs is guaranteed to 
stay basically the same. I.e. "bicycles allowed" is not going to mutate into 
"motorcycles allowed" etc. Applications need this to be able to assign icons to 
the attributes.

Original comment by following09 on 16 Apr 2013 at 10:46

[GoogleCodeExporter]

> Applications need this to be able to assign icons to the attributes.

... or to implement "stored queries"

Original comment by following09 on 16 Apr 2013 at 11:44

[GoogleCodeExporter]

Let's say that the first internal attribute is the "primary" one.

> This would at least enable OKAPI attribute replication beween databases of 
the same DB branch.

Why would you need to that? Can you give me a use-case?

Original comment by rygielski on 16 Apr 2013 at 1:28

[GoogleCodeExporter]

> Let's say that the first internal attribute is the "primary" one.

Hmm, that takes us only half way. We also need to know which *OKAPI* attribute 
ist the primary mapping for a *local* atttribute, otherwise we cannot construct 
something like primary_attr_ids.

> Why would you need to that? Can you give me a use-case?

Someone creates a website where where he publishes OC.de caches, e.g. all 
caches of a certain region or all own caches or whatever. He uses the OC.de 
iconset to display the listings, and everything shall look the same as on OC.de 
(which is also desirable to meet the ND data license, which does not allow 
modification of the cache listings). So he needs the 1:1 attributes from the 
OC.de database.

Original comment by following09 on 16 Apr 2013 at 1:41

[GoogleCodeExporter]

So, you want to tag some attributes as "1:1 attributes, which always have 
exactly one internal_id in OCDE". That is exactly why we made the categories 
many-to-many! If any of your developers would want to do such thing, then he 
may skip all attributes which do not belong to this category.

Original comment by rygielski on 16 Apr 2013 at 2:10

[GoogleCodeExporter]

No. I my idea is:

- allow multiple:multiple relations for all attributes
- tag one local->global relation for each local attribute as "primary"
- expose this information through the geocaches method, e.g. as a 
primary_attr_ids list, which contains the subset of ids from attr_ids which are 
primary representations of local attributes.

Then users have the choice: They can process *all* global attributes for that 
cache, or just those which can unambiguously be mapped back to the local 
attribute set of the cache.

Original comment by following09 on 16 Apr 2013 at 2:24

[GoogleCodeExporter]

It is not about categories at all, it is just about mapping local <-> global 
IDs.

Original comment by following09 on 16 Apr 2013 at 2:25

[GoogleCodeExporter]

I just notice that #95 will take us only half-way, too. Given a 
primary_attr_ids list, the user still does not know which local attributes they 
present, as one global attrib can be the primary for multiple local attribs.

Can you give examples of multiple:multiple attribute mappings that make sense 
and are necessary?

Original comment by following09 on 18 Apr 2013 at 2:11

[GoogleCodeExporter]

Make sence - yes. Necessary - no. But - and this is much more important - I 
cannot prove that they are *not* necessary.

I think we should publish that and wait for the actual use-case to emerge.

Original comment by rygielski on 18 Apr 2013 at 4:37

[GoogleCodeExporter]

My instincts tell me that we already will be in trouble when the first use case 
emerges, because some application(s) will already be replicating local 
attributes via OKAPI and expect that everything is fine. Then we might be 
forced to define the allmeta.attributes.internal_ids field as containing only 
one ID to retain backward compatibility.

What about adding an allmeta.attributes.internal_id field NOW, which exposes a 
1:1 local:global attriute relation? When the a 1:multiple relation will be 
necessary some day, we can think about how to implement it in attributes.xml. 
This would force developers think about what they are doing, i.e. if 
internal_id or internal_ids will be appropriate for their case. Docs can 
explain that internal_ids should be preferred and internal_id used only if 1:1 
representation of local attributes is necessary.

Original comment by following09 on 18 Apr 2013 at 5:44

[GoogleCodeExporter]

Ok, we will still get in trouble if we don't add another field to the geocaches 
method NOW, to distinguish between the 1:1 and the multiple:multiple relation. 
Otherwise some users would undestand attr_ids as 1:1 and others as 
multiple:multiple; this would end up in a similar mess like the submit.comment 
format thing.

Original comment by following09 on 18 Apr 2013 at 5:54