- From: Seiler, Karl <karl.seiler@navteq.com>
- Date: Mon, 7 Feb 2011 08:22:51 -0600
- To: "cperey@perey.com" <cperey@perey.com>, Jens de Smit <jens@layar.com>
- CC: "public-poiwg@w3.org" <public-poiwg@w3.org>
- Message-ID: <0B559C0AA6C114479A87C752A04E343E05D7269EC0@hq-ex-mb02.ad.navteq.com>
IDs. I included (and you inherited) the idea of associated IDs. My thought here was not to represent relationships, only to support the concept that IDs for the same location can change over time or go in and out of use, and this attribute provides linkage to the old IDs. Sometimes IDs are retired and replaced, or are depreciated and deleted. Since we are not going to provide any inherent sync-ing mechanism then one system can be carrying old / bad IDs. This attribute can convey a reference bad to old IDs, allowing out of sync systems to bridge their persistent IDs forward. Admittedly kind of obscure. Trustworthiness Trustworthiness : degree of certainty the author has in the accuracy of the object What makes an object more or less accurate? I think mobile things expect and require a higher degree of accuracy and therefore trustworthiness in the confidence in their location. The use cases get rare but render something like: we know it is moving, near or around this building, but we really do not know where it is right now. FYI - I did post a Location Primitive revision. _______________________________ Karl Seiler Director Location Technology & Services NAVTEQ - Chicago (T) +312-894-7231 (M) +312-375-5932 www.navteq.com<http://www.navteq.com/> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Christine Perey Sent: Sunday, February 06, 2011 4:07 AM To: Jens de Smit Cc: public-poiwg@w3.org Subject: Re: The Object Primitive Hi Jens, thanks for your excellent points! my replies in-line. On 2/2/11 1:53 PM, Jens de Smit wrote: Hey, Some feedback/thoughts/discussion points On Sat, Jan 29, 2011 at 9:59 AM, Christine Perey <cperey@perey.com><mailto:cperey@perey.com> wrote: I took the locations primitive which Karl provided http://lists.w3.org/Archives/Public/public-poiwg/2011Jan/0017.html as well as the suggestions from Roy Davies http://lists.w3.org/Archives/Public/public-poiwg/2011Jan/0007.html and created, based on those, a laundry list of what could be included in the "objects primitive". As Roy suggests and we discussed on the call January 26, an Object has a location but it can change over time (in which case it is a NON-FIXED POI), or not moving (in which case it is a FIXED POI). I welcome feedback. Regards, Christine Object Primitive Goal: Provide a rich and flexible description of an object (aka a thing) De-couple or isolate the description of an object and from where it is (a Place of Interest) and other primitives. An object has one location at a (temporary-duration undefined) specific point in TIME but does not have one fixed point over time. An Object of Interest can be a parent to other Objects each with its own description to allow for the representation of complex objects that are the aggregate of a collection of Objects (a car, boat, or airplane). It should not be inferred that each of the elements within the object primitive are not spatially synonymous, but do refer to the same object. High Level Attribution: Object Name Object's Absolute Location at last known time Why absolute? Could it not be relative to another location? If an absolute location is known, it could be added. If a relative location is known, it could also be added. I would suggest that both are optional but that either, if in the primitive, must have a time stamp. Identification Object's category [living, non-living] What is the (use) case for distinguishing living and non-living objects? I think many things can be inferred via the living vs. non-living ID. Having an idea, when available, of the object's living/non-living status may help with recognition and tracking algorithms, for example. Once you know it is living, and then know if it is an animal, then something may recognize the genus. Then, your algorithms will probably detect deformations more often in a specific zone (the head). non-living materials/objects can also deform (e.g., water, sand) but using different parameters. The more which can be quickly codified the lower the processing requirement, the faster the response times. By the way, I'm not attached to this/saying it is required, but I suspect it will have utility. Object's Attribution Details Identification ID (optional) Identification System or Service ID Associated IDs What is exactly the meaning of an "ID", a "System or service ID" and an "Assoicated ID". Don't know, really. Perhaps this is where one stores the living v.s non-living, etc These were part of the Location Primitive so I kept them. I think the Associated IDs would be helpful if an object is part of a larger entity (e.g., the component of a computer, or anything else which is composed of multiple objects) Name Last Updated On : Date/Time (optional) Updated By : owner / author (optional) Use : public, private, restrictions (optional) Ownership info : owner of all or part of a POI Cost - each point can cost more for the people who lease it from the layer owner. This seems to come directly from look-here.biz. What's the use case for that? You are correct. This was integrated from Roy Davies' post. Cost can be unknown, known, it can be flexible (more for me that for a member of a club). I think that having information about the value in monetary terms might be important if you are in a shopping application. Status : Active, blocked, deleted (optional) This is usually (if not always) in relation in a certain context. I do not see how an object of itself can be "active" or "blocked". If it's deleted, doesn't it just disappear? Yes, but once again, these were "inherited" from the location primitive and my goal was to keep the two as similar to one another as possible. Trustworthiness : degree of certainty the author has in the accuracy of the object What makes an object more or less accurate? Good catch. It should be a relative assessment of the accuracy of the information, not of the object. Category Object (optional) Type Living - composed of one or more cells Non-living - inanimate, not composed of cells [Then we can classify according to animal or plants, mammal, etc!] Again, what is the use case for this classification system? Addressed (to the extent I can) above. If you are going to assign a business code to places (e.g., the place is commercial, this kind of a commerce, etc) then, why not have taxonomy in the sense of "nature"? Just thinking outside the box!! MORE OPTIONAL INFO ABOUT OBJECTS: Circumference/radius (the description applies to this Object plus the space around it?) Isn't this covered in Location? An object is linked to a Location, which defines its spatial boundaries... Not necessarily. If the object is not linked to a location, then this rule does not hold. And the POI might refer to simply the size, if it is known, in order to aid with the recognition of how far away it is from the user, how to display the digital data in relation to it, etc. Is it planar or 3D? If it is planar, what are its X&Y dimensions? This is the equivalent of area for the location primitive. If it is 3D, what is known about it? Volume Density Identification (optional) Supplier: who made this object? Version: what is its version? Associated Object ID Trustworthiness of this information? What are its relationships to other objects? Is it near a fixed object? How near? Does it belong to someone? A company or an individual? Connected- Part of a larger entity (a motor?) Independent- not part of a larger entity 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 Monday, 7 February 2011 14:23:30 UTC