[Wasabi] Kicking of the Metadata spec - brainstorm

[Sebastian Trüg]

On Wednesday 07 March 2007 21:13:19 Mikkel Kamstrup Erlandsen wrote:
> From a technical standpoint I think rdf and ontologies are great, but from
> an application developers viewpoint they seem overly complex for most tasks
> I could think of. Most things can be done if you just know a list of
> metadata fields to query.

The thing is that in Nepomuk we do much more than just local search. The main 
focus is more on creating relations between resources and exploiting these 
relations for the benefit of the user. RDF and ontologies provide a lot of 
power in this area.

> Another concern is that a full sematic framework raise the bar for
> implementations. It should be possible to have real simple implementations
> of the specs - or atleast provide a good portion of the functionality via a
> simple implementation (fx. a daemonless service spawned by dbus activation
> on each call).

That is true. But one could think of a simple mapping from the full-fledged 
version to a simple key-based variant which makes up the wasabi metadata 
fields. When searching certain fields nobody wants to enter the full URI of 
some metadata type or element.
Actually each RDF property and class is supposed to have a human readable 
label. This label is not necessarily unique but it would probably suffice for 
a simplified query interface. Thus, the API could support the usage of the 
full type and property URIs and the mapping from the simple labels.

> Also, embedded devices should be able to implement the Wasabi specs (or
> again - the essential parts atleast). I must admit I have no idea on the
> feasibility of this - it might not be a problem at all.
>
> The ideal solution would be to allow a full fledged semantic framework
> underneath it all, but expose apis that does not require developers to know
> about rdf and ontologies. There could be a "semantic api" or some optional
> extensions to the current apis to allow usage of the full semantic
> sweetness.

we could even think of wasabi as being the "simple" standard which maps to the 
full-fledged semantic information. In the end it is most important that the 
information can be reused.

>
> Another thing - how does the Wasabi query language (
> http://wiki.freedesktop.org/wiki/WasabiQueryLanguage) fit in a Neopmuk
> context? Does it allow you to do the things you want to do, or do you plan
> on using an existing standard?

Actually we need more. That is also what the workshop is intended to solve. We 
need a query language that allows exploring all the resource relations that 
are stored. One approach ATM is to combine SPARQL with a simple full text 
searching mechanism but that is far from perfect.

>
> Cheers,
> Mikkel
>
> > On Monday 19 February 2007 23:35:07 Mikkel Kamstrup Erlandsen wrote:
> > > Let's get the ball rolling on the metadata spec. This first period will
> > > just be *brainstorming*, so let's try and avoid the nitty gritty
> > > details for now.
> > >
> > >  ** What we need:
> > >
> > >   Fields)  Metadata field names and descriptions for *desktop* objects
> > >
> > >   Types) A type grouping of metadata fields to be used in user search
> > > language. Example types could be "Email", "Image", "Audio", etc.
> > >
> > >   API) A dbus api to get/set metadata
> > >
> > >   ?Tag/Emblem) Tagging/Keywords/Emblems
> > >
> > >  ** Starting points/References:
> > >  - Adobe XMP:
> >
> > http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pd
> >f <
> >
> > >http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec> -
> > > Shared Metadata Spec:
> > > http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadata_2dspec
> > >  - Tracker metadata api:
> >
> > http://svn.gnome.org/viewcvs/tracker/trunk/data/tracker-introspect.xml?vi
> >ew
> >
> > >=markup - Spotlight Metadata Spec:
> >
> > http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribu
> >te
> >
> > >sRef/Reference/CommonAttrs.html
> > >
> > >  - Shared Emblem Spec:
> > > http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec
> > >  - Others ideas? Nepomuk-specs? Beagle-specs?
> > >
> > >  ** My thoughts:
> > > Regarding Fields): To prevent death-by-1000-page-spec I suggest we keep
> >
> > the
> >
> > > field names to a core set of commonly used attributes. Ie not like
> >
> > Apples
> >
> > > spotlight spec (see above) which defines every known property in the
> > > universe. When things move on, teams with expert knowledge can refine
> > > extensions to this spec. Fx a Wasabi Photography Metadata spec could be
> > > hashed out by people in the know (which could just be EXIF, but I'm not
> >
> > the
> >
> > > photography expert).
> > >
> > > Regarding Types): There are some suggestions in the top of the Tracker
> >
> > api
> >
> > > link above. Regarding these I think we should leave the VFS* types out,
> >
> > and
> >
> > > only use single-word type names (Ie no spaces).
> > >
> > > On the API): Obviously we getters and setters. They probably need to
> > > operate on uris. There probably needs to be some search functionality
> > > in here too since we probably shouldn't assume that the indexer and
> >
> > metadata
> >
> > > server are the same.
> > >
> > > Tagging/Emblems: If you ask me they should be "just another type of
> > > metadata". When the metadata spec matures a bit we can evaluate if it
> >
> > needs
> >
> > > it's own api to make things easier (and allow for dedicated tagging
> > > services).
> > >
> > > Cheers,
> > > Mikkel
> >
> > _______________________________________________
> > xdg mailing list
> > xdg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg