2007/5/18, Joe Shaw <[EMAIL PROTECTED]>:

Hi,

On 5/18/07, Evgeny Egorochkin <[EMAIL PROTECTED]> wrote:
> Can you provide a more concrete example of why you can't e.g. define a
> Object.HitType field instead to provide the same functionality?

Oh, there's no reason why you can't.  In fact, this is exactly what
Beagle does.  There is no object hierarchy concept in Beagle results,
every returned result is a "hit" and contains properties.

Basically, the values for HitType and FileType indicate a contract to
clients about what types of properties to expect.  A HitType of
"File", for instance, means that beagle:ExactFilename will be set.  A
GUI wouldn't attempt to display beagle:ExactFilename if HitType
weren't "File".

> What specific fields do different hit types have?

The only ones that come immediately to mind are the ones for File.
Things like beagle:ExactFilename, beagle:Extension, beagle:Filename,
beagle:NoPunctFilename, beagle:SplitFilename.  You can imagine similar
properties for items which come from emails, like "folder" or
"attachment title".  These are independent of the content or type of
the document being indexed itself.


Putting the EmbeddedObject stuff aside for a moment...

Would the HitType/FileType structure of Beagle not be implicit with a
Category structure like this:
http://www.grillbar.org/xesam/object-tree.png(this is not the old
example again)? Especially if you couple this with a
Field->Category map (such that, fx, only Objects of category File has the
ExactFileName field set) like the Strigi/Nepomuk camp want. Atleast it seem
to cover the examples so far.

Cheers,
Mikkel
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to