[Xesam] Practical applicability issues

Jos van den Oever jvdoever at gmail.com
Thu Jun 19 14:59:52 PDT 2008


2008/6/19 Arun Raghavan <arunisgod at gmail.com>:
> Again, I do not want to imply that the spec should be constrained, but
> there should be some way in which the simplicity paradigm can be
> maintained in parallel with more advanced features/usage.

I agree with Arun. Adding structs to the spec will make it complex to
implement and complex to query.
For desktop search I think it is best to have Xesam for simple things
and Sparql for arbitrarily complex things. In Xesam, one can now query
one relationship: does resource X have value Y in property Z. Adding
structures would give us an extension to member W of property Z.
Sparql and triple stores allow one to do arbitrarily deep queries. The
added value for these is not as large as finalizing a common desktop
spec.

If you want more complex search possibilities the current version of
Xesam allows you to define 'subresources' which can have properties.
This is not pretty but may be a solution for some pressing problems.
E.g. if we have a property location, we could have
 janis.vcard/Address match City:Ajax

This is ugly though.

The main goal of this spec is to find files quickly. If you want to
find people from Ajax, you can find the relevant vcard now. But you
cannot filter on the property in the vcard the city matches to. This
is no big deal to me. I've done the initial filtering.

Cheers,
Jos


More information about the Xesam mailing list