W3C home > Mailing lists > Public > public-poiwg@w3.org > February 2011

RE: ID primitive

From: Seiler, Karl <karl.seiler@navteq.com>
Date: Thu, 24 Feb 2011 10:22:06 -0600
To: Alex Hill <ahill@gatech.edu>, "Seiler, Karl" <karl.seiler@navteq.com>
CC: Jens de Smit <jens@layar.com>, "Public POI @ W3C" <public-poiwg@w3.org>
Message-ID: <0B559C0AA6C114479A87C752A04E343E05D74CD7AE@hq-ex-mb02.ad.navteq.com>
I like using the URI model for Place IDs

_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com<http://www.navteq.com/>

From: Alex Hill [mailto:ahill@gatech.edu]
Sent: Thursday, February 24, 2011 10:16 AM
To: Seiler, Karl
Cc: Jens de Smit; Public POI @ W3C
Subject: Re: ID primitive

Can you be more specific, Karl?

On Feb 24, 2011, at 10:13 AM, Seiler, Karl wrote:


I like the idea of proposing a Places unique and persistent ID model is a unique object URI.


_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com<http://www.navteq.com>


-----Original Message-----
From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Jens de Smit
Sent: Thursday, February 24, 2011 3:15 AM
To: Public POI @ W3C
Subject: Re: ID primitive

All right,

Let's say we use URIs as identifiers. What would be the consequences?

- URIs are inherently less compact than binary numbers, so consumer
more storage/bandwidth
- URIs can carry semantic meaning. Is this a potential problem, a benefit, both?
- would we allow any URI or only dereferenceable URIs (to support linked data)?


I think Karl made a good start with a list of requirements. Let's
address those while we're at it:

*         Unique - not-named-based identification

I think we can come up with a unicity agreement fairly easily. I'm not
sure what Karl meant by "not-named-based identification"

*         Key - able to be used as a primary key

URIs are simple character strings. IRIs are a bit more complex as they
can contain multi-byte characters, but modern data storage systems can
handle this. I see no technical objection against using URIs as
primary keys, unless an expert can argue to me that this is horribly
inefficient and will cause systems to break down.

*         Persistent - does not change unless a key large scale change
to the object warrants (rare)

URIs are very good at being persistent. Judging from all the broken
links in the internet, many URLs are still around even though their
associated content is not...

*         Efficient - does not consume large bandwidth to distribute

URIs tend to be more verbose than numbers. However, unless people go
out of their way to create huge URIs any single URI should fit within
the MTU of almost any network in existence. Compared to all the
overhead of a transfer I'd say a URI is efficient enough.

*         Informative - can potentially contain some high level
information about the object to circumvent always having to complete a
round trip to the content service to determine if the object is of
interest (country code, basic type - point, line, area, ownership  -
private, public)

URIs can contain quite a bit of info. We must take care not to try and
fit the whole spec into a URI though, just critical information...


Okay people, time to associate freely :)

Jens



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.

Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology
http://www.augmentedenvironments.org/lab



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, 24 February 2011 16:22:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:27 UTC