[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
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.
More information about the Xesam