Xesam meta-meta-data spec needs attention.

[Sebastian Trüg]

Hmm, so now you ignore RDF?
Don't get me wrong, it is your project, so in the end it is your decision.
I am just a little confused why we have this wiki page then. :)

Cheers,
Sebastian

On Tuesday 01 May 2007 06:56:30 Mikkel Kamstrup Erlandsen wrote:
> 2007/4/30, Phreedom <phreedom.stdin at gmail.com>:
> > I'm writing this on behalf of Strigi project.
> >
> > It's important to finish Xesam specs as soon as possible since lots of
> > code
> > and work starts to depend on meta-meta- and meta- data spec and it gets
> > more
> > and more complicated to make changes.
>
> Thanks a ton for picking up on this. I have not been able to yet myself
> since I have been utterly swamped in real-world chores. It will be better
> after 5/5.
>
>
> I believe Xesam metadata bainstorm wiki page has shown that proposals
> mostly
>
> > split along .desktop vs RDF representation line, with the essense being
> > very
> > similar. So it's about time to finish meta-meta-data and start actively
> > working on meta-data spec.
> >
> > Another concern is KDE feature freeze on 1th june which is also going to
> > affect our ability to implement Xesam.
>
> I was wondering about that. I shall try and update the roadmap later today
> to accomodate for this.
>
>
> At the end of the e-mail is our lastest proposal for meta-meta-data
>
> > specification.
> >
> > Best wishes,
> > Evgeny
> >
> > Format specification of .fieldproperties files(DRAFT)
> >
> > =========================================================================
> >=============
> >
> > [Field]
> > Uri=$URI
> > ParentUri=$PARENTURI
> > Name=$NAME
> > Name[$LANG]=$LOCALIZED_NAME
> > Description=$DESCRIPTION
> > Description[$LANG]=$LOCALIZED_DESCRIPTION
> > TypeUri=$TYPE
> > Values=$VALUES
> > Values[$LANG]=$LOCALIZED_VALUES
> > Range=$RANGE
> > MinCardinality=$MIN_CARDINALITY
> > MaxCardinality=$MAX_CARDINALITY
> > Indexing=$INDEXING
> > Relevance=$RELEVANCE
> > Comment=$COMMENT
> >
> > $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.
>
> $PARENTURI
>
> >   URI of parent property. Parent relation is similar to inheritance.
> > Usually
> > child property
> >   introduces some specifics/limitations/implications compared to its
> > parent.
> >
> > $NAME(required), $LOCALIZED NAME
> >   Short user-friendly name. This is the name users will see when file
> > metadata
> > is displayed to them.
> >
> > $DESCRIPTION(required), $LOCALIZED_DESCRIPTION
> >   User-friendly property description. This is the description of property
> > suitable for tooltips.
> >
> > $TYPE(required)
> >   Property data type.
> >   Valid values: string, string_enum, string_enum_ext, integer, float,
> > boolean,
> > datetime, binary.
> >   string_enum type is a property that can only take one of the list of
> > valid
> > values provided by $VALUES.
> >   string_enum_ext type is a property that can take any string value,
> > however
> > $values list provides
> >   suggested values of this property.
> >
> > $VALUES(required if $TYPE=string_enum or string_enum_ext),
> > $LOCALIZED_VALUES
> >   Property value constraints. Default =  no constraints.
> >   if $TYPE=integer|datetime|float, $VALUES=value1|value2|value3
> >   if $TYPE=string, $VALUES=validation regexp
> >   if $TYPE=string_enum, $VALUES=value1|value2|value3
> >   if $TYPE=string_enum_ext, $VALUES=value1|value2|value3|*(or)
> >   This syntax lets us directly use $VALUES as a regexp for validating
> > user input. Yet it's syntax
> >   is developer- and translator- friendly.
> >   Suggestions on regex subset are welcome. KDE and Strigi is going to use
> > QValidator and QRegExp for this.
> >
> > $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.
>
>
> $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?
>
>
> $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 :-)
>
>
> $RELEVANCE
>
> >   Defines how relevance of the file is affected if a match is found in
> > this
> > field. Default = 1.0
> >
> > $COMMENT
> >   Developer comment. Users won't see this.
>
> Overall I agree. The biggest issue is the group header as I comment above.
>
> Thanks again for picking up on this! Cheers,
>
> Mikkel