- From: Thomas Wrobel <darkflame@gmail.com>
- Date: Thu, 5 May 2011 18:29:52 +0200
- To: roBman@mob-labs.com
- Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
Personly I think we should ignore any concept of colections, at least for the moment. It would be very delivery method specific. We should concentrate on what we are delivering first and then see if a packaging standard is needed for it. I'm also wary of going too xml specific with anything which I feel could be a slippery slope. POIs should certainly have a unique ID though. Domain and a token maybe? ~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 5 May 2011 01:01, Rob Manson <roBman@mob-labs.com> wrote: > This also raises the issues around collections in general mapped out in > the strawman. > > What is the goal of the pois collection wrapper? > > Perhaps it would be better if we just started at the more granular level > of the poi then clarified the use cases for the collections. > > I think it's important that an individual poi can have a unique URL > based ID - effectively making this a permalink or similar. This then > relates to the POI/language points in this thread. > > However, if we do wrap a collection of poi in a pois tag then we should > think about what else the existing Mobile AR formats also allow in terms > of meta information added at this top level. KML, Layar, etc. This is > kind of similar to the DOM based head/body separation in HTML and is > very useful. > > If the collection is designed for responses to Queries then it should > probably at least support pagination related meta data. > > If the collection is designed for local serialised storage then > cache/created/modified data would be useful. > > Lots of other options here based on the use cases. > > > roBman > > > > > On Wed, 2011-05-04 at 21:55 +0200, Thomas Wrobel wrote: >> I don't think we should be specifying out anything other then the data >> encoded in the POI at this stage - designing systems to deliver >> different content for different clients I think should be well beyond >> our scope for now. >> >> I do agree that encoding all languages in all POIs would make >> downloads way too big....but then is this a realistic situation? Most >> content creators aren't going to be specifying much more then their >> local language. We don't see many bilingual webpages. (on the same >> page) >> >> On the other hand, having separate POIs for each many be the simplest >> solution, as many parts of the POI could be effected by the language, >> not just the name. Even the data the POI links too might vary. (ie, >> linking to different wikipedia pages). >> >> I think its likely that whatever delivery system your using to get the >> POIs to the client will deal with language itself. For example, if >> they are at a url, you'd just have a different url for each language. >> If its from a database, the request could contain a language spec. If >> its an XMPP system, the subscription would be just to channels in your >> language (if you wish). >> So I think theres lots of delivery methods - all they need in common >> is for the POI to specify what language its in. >> >> We certainly wont be delivering all POIs to all clients in either case. >> >> [/ideas] >> >> ~~~~~~ >> Reviews of anything, by anyone; >> www.rateoholic.co.uk >> Please try out my new site and give feedback :) >> >> >> >> On 4 May 2011 21:22, Raj Singh <rsingh@opengeospatial.org> wrote: >> > I'm not thinking of alternate names, but the same name in different languages. For example, geonames has names for each place in a hundred different languages. We certainly don't want all those transmitted on every request for the POI , and absent a service call specifying the language to use, we don't have another way to be concise. Maybe something in the HTTP request header to do this? >> > >> > --- >> > Raj >> > >> > >> > On May 4, 2011, at 3:08 PM, "Seiler, Karl" <karl.seiler@navteq.com> wrote: >> > >> >> Suspect not the best idea. A POI will need to be largely atomic. Having to send a bundle of POIs just to get the language translations and transcriptions could explode the transmission sizes if we are not careful. >> >> >> >> POI names come with the following trappings: >> >> + root name >> >> + small set of typical synonym names (DBA names) >> >> + multiple language presentations of that name >> >> + voice TTS transcriptions of the names for spoken word / hands free ops >> >> >> >> This name proliferation is not really that rare. My guess is upwards of 30% of the standard POI sets carry multiple names. The more common and popular POIs have the most alt names. O'Hare / ORD / Ohare / O'Hare International Airport... >> >> >> >> _______________________________ >> >> Karl Seiler >> >> Director Location Technology & Services >> >> NAVTEQ - Chicago >> >> (T) +312-894-7231 >> >> (M) +312-375-5932 >> >> www.navteq.com >> >> >> >> >> >> -----Original Message----- >> >> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Raj Singh >> >> Sent: Wednesday, May 04, 2011 1:25 PM >> >> To: Matt Womer >> >> Cc: public-poiwg W3C >> >> Subject: POI Core strawman: multi-lingual >> >> >> >> Putting every possible language into a single POI could get very cumbersome. How about putting each different linguistic representation of a single POI in it's own <poi>, and linking them with an "identity" relationship? >> >> >> >> --- >> >> Raj >> >> The OGC: Making location count... >> >> http://www.opengeospatial.org/contact >> >> >> >> >> >> >> >> >> >> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. >> > >> > >> >> > > >
Received on Thursday, 5 May 2011 16:37:05 UTC