On Saturday 05 May 2007 01:08:51 Mikkel Kamstrup Erlandsen wrote: > I think that metadata constructs so complex that they require several files > to be described are out of scope for XESAM. We wan't to create a common > interface that everyone can implement. If you suddenly require that the > implementation support arbitrarily complex RDF structures I think we narrow > the would-be implementors down quite a bit. > > Another thing is that the search spec is not designed to query complex > metadata structures anyway. > > I fear that we end up with an over engineered spec if we wan't to allow > arbitrarily complex metadata. Basically I can't see the need to build > metadata structs/classes. Take the example of a Java-file. It could have a > metadata model where the class has methods and the methods have > documentation and arguments and so on. It's all great, and you could do all > sorts of fancy queries against it, but I honestly find it hard to believe > that it is worth the effort. You can get almost as good functionality with > the flat field proposal that was put out initially (fields still have > parents).
The first revision of xesam is unlikely to contain anything complex for the reasons you mentioned as well as it'd delay xesam for quite a while. Our discussion with Jamie was about extensibility/flexibility, a "what-if" scenario. > I'm not saying that there aren't any cases where a complex metadata model > is of great benefit, but do we need to encumber the whole xesam standard > with that? I mean with the Java-class example above wouldn't that > functionality be part of an IDE anyway? I would rarely wan't to search for > argument types of a method from my general desktop search tool. Many apps(e.g. Kate) already have search. Why bother? :) I don't think there's any code browser capable of working with all popular languages. Complex data model benefits apps which in turn benefit users. There's little direct benefit though. > > This is an example of an actual RDF serialization + named graphs > > extensions(which does support localization as suggested by Sebastian) > > > > @Prefix ...................... // 1-2 lines copied intact for all files > > @Base ...................... > > > > Mp3.Title > > is_a field; > > of_type string; > > name "Title"@EN; // not sure I got intl > > syntax right from the get go > > name "Titel"@NL; // but likely so > > description "Mp3 title" > > ... > > comment "example". > > > > Mp3.artist > > is_a field; > > of_type string; > > has_parent Content.Creator > > name "Artist"; > > description "Mp3 artist"; > > ... > > comment "example". > > Thanks for the example. What is the name of the language you use here? I > got lost in the debate somewhere :-) > It looks simple and clean and I don't have anything against it as such. It's a one of N3(Notation 3) syntax derivatives. You can think of it as RDF-XML(RDF minus XML) :) TriG(http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/Spec/) further tweaked by creating mappings xsd:integer ->xesam:integer, rdf:property->xesam:field etc and making xesam: default namespace (that's what @prefix and @base are for) > I'm still in favour of .desktop though - the main cause is simply that the > .desktop is used everywhere already. Let's stick to one format I say. I'd say RDF is used everywhere :P _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
