Xesam meta-meta-data spec needs attention.

[Mikkel Kamstrup Erlandsen]

2007/5/1, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> On Tuesday 01 May 2007 07:56:30 Mikkel Kamstrup Erlandsen wrote:
> > > $URI(required)
> > >   Unique resource identifier of the property. Internally properties
> are
> > > identified by this ID.
> > >   Alternative to this would be [$URI] instead of [Field].
> >
> > I would go for the alternative since we need this to be able to have
> > multiple field defs in one file. This is because the format spec for
> > .desktop files requires that group headers are unique. I know we can't
> > follow the .desktop spec to the letter but we might as well aim as close
> as
> > possible.
>
> We'll do as you say.
>
> > > $RANGE
> > >   Numeric property allowed value range. Default = no constraints.
> > >   $RANGE=[minValue,maxValue>
> > >   [ and ] = inclusive. < and > = exclusive.
> >
> > Can you mix the braces like [0,1>. I'm not 100% sure this syntax is
> > possible with a .desktop like spec. I'm mostly worried about the ['s
> also
> > used for group headers.
>
> We could use {} or () instead.
>
> > $MIN_CARDINALITY
> >
> > >   Minimum cardinality. Minimum number of properties of this type you
> must
> > > set
> > > for a given file.
> > >   Lets specify mandatory properties. Default is 0.
> >
> > Is there any example of a mandatory property? Does it even make sense?
>
> File name or URI?



I don't see why they have to be mandatory. Not everything comes from a file.

In the search API it is specifically avoided to use global identifiers for
objects - as fx a mandatory uri would be. My opinion is that we shouldn't
*force* URIs or any mandatory property onto any object.


> $MAX_CARDINALITY
> >
> > >   Maximum cardinality. Maximum number of properties of this type you
> can
> > > set
> > > for a given file.
> > >   Default is infinity.
> > >
> > > $INDEXING
> > >   Values=fulltext, atomic, none, TBD. Default = TBD.
> >
> > Can you please describe what these values mean? I think I get it, but
> let's
> > be sure :-)
>
> I'm not sure myself :)
> Fulltext is supposed to be indexed for full-text search.


So fulltext is text that should be tokenized, filtered for stop words,
stemmed, and indexed, right?

Atomic is for numbers, enum-like fields(controlled vocabulary)


Atomics should be indexed as one searchable chunk. No stemming, splitting,
filtering. Just stick it in the index..?

What about TBD?


None is self-explanatory.


Yes - don't index this field. But I take it you can still retrieve the value
of it... Or else there is no reason defining the field in the first place...

I'd appreaciate feedback on this. Is it always possible to derive this from
> field type or not?


I don't think you can derive it always. Think of some app that stores some
unique string ID along side all objects. It might want to be able to search
for these IDs, but it surely don't want them tokenized just because they
might contain a space. In this case the app would want to use
INDEXING=atomic.

I've intentionally omitted field properties IsWritable and
> IsIntrinsic(Embedded). The reason for this is we never know in advance.
> These
> values should be queried for specific files.


Yes. We discussed this on IRC and ended up agreeing that it belongs as
methods in a Metadata service API.

This reminds me that we could use an IRC channel somewhere...

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070501/fcb4fb57/attachment.htm