2007/5/1, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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?</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> $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.</blockquote><div> So fulltext is text that should be tokenized, filtered for stop words, stemmed, and indexed, right? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Atomic is for numbers, enum-like fields(controlled vocabulary)</blockquote><div> Atomics should be indexed as one searchable chunk. No stemming, splitting, filtering. Just stick it in the index..? What about TBD?  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">None is self-explanatory.</blockquote><div> 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... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd appreaciate feedback on this. Is it always possible to derive this from field type or not?</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> Yes. We discussed this on IRC and ended up agreeing that it belongs as methods in a Metadata service API. </div> This reminds me that we could use an IRC channel somewhere... Cheers, Mikkel </div>