On Monday 30 April 2007 23:40:37 Phreedom wrote: > 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. > > 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. > > 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 agree with Mikkel here that we should not have multiple groups with the same name. > $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. How about using xml schema types here. That way a later mapping to RDF will be easy and Nepomuk can stay compatible without an artificial mapping. The only problem here are the enumerations. XML Schema does support creating enumerations but I think they are complex types. How about this: the type will stay a string or an int or whatever. But if the VALUES field is set it is to be treated as an enumeration. I don't think we need the extra types here. > $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. Actually there is no need to have RANGE and VALUES. Just merge them into range: RANGE=1,4,5,2.3 RANGE=1-7 RANGE=hello,bello,wello > $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. > > $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. what is this supposed to do? > $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. > _______________________________________________ > xdg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
