[XESAM] Minutes of meeting 2007-05-23

Sat May 26 03:02:17 PDT 2007

2007/5/24, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>
> Minutes of meeting, 2007-05-23
>
> <MINUTES>
>
> Attending: Jos, Jamie, Joe, Evgeny, Sebastian, Mikkel (and later Antoni
> Mylka (of DFKI))
>
> Note: We decided to call .desktop .ini instead since .desktop is really
> wrong in this context. I shall use .ini in this recap.
>
>  - We started out talking about zesam in general terms - what the project
> was really about.
>  Kamstrup thinks that xesam is about providing a simple interface for
> dedsktop search and metadata that can be implemented in many places and
> forms. He would also like to adhere as much as possible to the KIS
> principle, especially in this first iteration.
>   Not many objections to this. It was pointed out that xesam should never
> try and be as general as Nepomuk. This was also really far from being the
> case.
>   Sebastian aired that xesam potentially could be a part of nepomuk.
>
>  - Kamstrup suggests a hearing round where everybody can express their
> points regarding the metadata spec.
>
> Jamie: Is pro a .ini-approach because:
>  1) they are in wide use
>  2) toolkits can use them
>  3) translators can use them
>  4) its the least amount of work
>  5) its easy for third party apps to ship metadata .ini files
>
> Joe: Don't really care how the serialization format of the ontology turns
> out. Beagle will not be using it near-term anyway. He stresses that it is
> mostly the field conventions that are used by actual metadata extraction
> programs.
>   He is not keen on the idea of apps dynamically create UIs from the
> ontology. You need to present the metadata in a way that suits the context,
> not just a list of fields.
>
> Kamstrup: Wants to keep everything as simple as possible in the first take
> until we are sure what out needs are. Also he want the spec in  entirety to
> be grokkable by most without a search/metadata background at a glance. He
> prefers the .ini approach.
>
> Evgeny: Also want to keep it simple for devs. He believes that Turtle is
> as easy to understand as .ini - atleast if we restrict our selves to the
> subset of Turtle that we need (not allowing full lown Turtle). Also a Turtle
> based ontology can be viewed and edited with visual tools. If we impose any
> new conventions in the .ini format it will be as hard to parse as Turtle.
>
> Sebastian: In addition to Evgenys points he will like to point out that
> Turtle is a well known standard for ontologies. Also other tools can use the
> xesam ontology if it uses Turtle and we can adopt 3rd party ontologies as
> well.
>
> Jos: Thinks that we should concentrate work on:
>  - focus on the fields we allow search in, file types/categories are a
> bonus
>  - focus on what we define for the fields
>  - agree on default shortcuts for the fields
>  - agree on the data types we use in the fields ( preferrably closely
> linked to XML Schema types)
>  - describe units (meters, amperes, Hz) and define a default unit per
> field
>  - work on a test set to check conformance to the spec
>  - should make the distinction between embedded and not embedded
>  - focus on fields for now because it's less work
> Considering the format he thinks .ini is ugly but simple, and that we use
> it in the wrong way - group headers should have well defined names, not just
> arbitrary field names. He would like an RDF representation, but it need not
> be the only representation. Also there are tools to check the validity of an
> RDF ontology.
>
> Kamstrup and Jamie chimes in and claim that it is indeed legal to use
> arbitrary group headers in .ini. Fx, like in the icon-naming-spec.
>
> Joe would like to know how i18n works in Turtle.Evgeny has an example here
> http://lists.freedesktop.org/archives/xdg/2007-May/008252.html. He points
> out that the translation infrastructure (in Gnome) is already ready for .ini
> and xml files.
>
> The complexity of implementing a Turtle parser in C is discussed. It seems
> unclear what the requirements for such a parser would be in our case where
> we don't need full Turtle. We haven't decided on a Turtle subset yet, so...
>
> It is proposed that we use both .ini and rdf/Turtle. This is quickly shot
> down since we need 3rd party extensibility and apps need to be able to parse
> the ontology if they wish.
>
> Antoni Mylka (of DFKI) points to the Raptor Turtle parser. A C library
> licensed under Apache2 and LGPL-2.1 (choose one).
>
> Mikkel suggests that Tracker could use libraptor as a start out (or some
> inlined pieces) and move to a real glib based one at a later point if Raptor
> is to big a dependency.
>
> Jamie will accept Turtle if Gnome developers and translators will accept
> it.
> Kamstrup promises to go out and get some opinions.
>
> Mylka advertises http://www.dfki.uni-kl.de/~mylka<http://www.dfki.uni-kl.de/%7Emylka>on xesam vs nepomuk.
>
> Mikkel tries to get some opinions on
> http://wiki.freedesktop.org/wiki/XesamSearchUpdates. Jos acknowledges all
> changes except part 5 about dbus objects instead of plain handles. Since
> Fabrice said the same in a private mail to Mikkel, they will be merged.
>
> </MINUTES>
>
> IRC log available from
> http://wiki.freedesktop.org/wiki/XesamMetadataFieldsDraft

The search spec has been updated as described by
http://wiki.freedesktop.org/wiki/XesamSearchUpdates, except pount 5 about
native dbus objects.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070526/d27f7306/attachment.html 