Xesam meta-meta-data spec needs attention.

[jamie]

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

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
>