xml-dev Feb 1998: Re: Automating Search Interfaces

------=_NextPart_000_008E_01BD3E0C.844A6680
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>I would like to talk about the location of the person making the search =
versus the location of the product or service provider. If I search for =
a product and I want it now, I only want a list of provider in a =
distance applicable for my request. And if I go to Europe this summer =
and want to make reservation or search for activities occuring at that =
time, the 'where I am' specification change. If I have a secondary house =
and make request on the week-end, I want the restaurant in that region =
and not the one near my primary house. An identity profile should be =
include in the query and give the chance to the search engine to make a =
better choice in regard of my age, sex, etc...

Address or map coordinates? How does one find map coordinates? What =
happens when he moves?

If a vendor has all inventory at a single location then the location can =
be #FIXED in his DTD. If inventory is distributed around the globe, =
each product or inventory group will have to be marked. The problem is =
that now it makes no sense to indicate physical location. It will have =
to be a store code which causes problem with search services since store =
codes will have to be converted into location format used by the search =
service.

As far as time constraints go, each product will probably be marked with =
time. The problem is that some time constraints are relative in nature.

*Ouch* I just thought of another painful problem with prices. What =
happens when a store wants to put on a sale? His database of products =
will have to map to different pricing schemes constrained by time, =
location, or association.

------=_NextPart_000_008E_01BD3E0C.844A6680
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>I would like to talk about the location of the = person=20 making the search versus the location of the product or service = provider. If I=20 search for a product and I want it now, I only want a list of provider = in a=20 distance applicable for my request. And if I go to Europe this summer = and want=20 to make reservation or search for activities occuring at that time, the = 'where I=20 am' specification change. If I have a secondary house and make request = on the=20 week-end, I want the restaurant in that region and not the one near my = primary=20 house. An identity profile should be include in the query and give the = chance to=20 the search engine to make a better choice in regard of my age, sex,=20 etc...

Interesting. Some of the = issues with=20 product location are:

1. How to indicate location?

Address or map coordinates? How does one find = map=20 coordinates? What happens when he moves?

2. How to associate location with = products?

If a vendor has all inventory at a single location = then the=20 location can be #FIXED in his DTD. If inventory is distributed = around the=20 globe, each product or inventory group will have to be marked. The = problem=20 is that now it makes no sense to indicate physical location. It = will have=20 to be a store code which causes problem with search services since store = codes=20 will have to be converted into location format used by the search=20 service.

As far as time constraints go, each = product will=20 probably be marked with time. The problem is that some time = constraints=20 are relative in nature.

*Ouch* I just thought of = another painful=20 problem with prices. What happens when a store wants to put on a=20 sale? His database of products will have to map to different = pricing=20 schemes constrained by time, location, or association.

All this hurts my head a bit but it = is very=20 interesting indeed...

Regards,