Xesam meta-meta-data spec needs attention.

Wed May 2 19:08:32 EEST 2007

On Wednesday 02 May 2007 14:46:15 jamie wrote:
> On Wed, 2007-05-02 at 14:13 +0200, Sebastian Trüg wrote:
> > 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. :)
>
> Im too busy (until mid-may) to comment on the spec in much detail
>
> perhaps we can arrange an online discussion mid may to flesh this all
> out

good idea. Since my workshop pretty much failed (mostly my fault)...

> I have a few concerns with the nature of the proposed desktop file spec.
>
> I agree its important the desktop file should be easily convertible to
> rdf but we do want to eliminate the complexity (and extra overhead of
> rdf) as much as possible from it - that is the point of having the
> desktop file.
>
> jamie.
>
> > 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
> >
> > _______________________________________________
> > xdg mailing list
> > xdg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg