[Wasabi] Kicking of the Metadata spec - brainstorm

Thu Mar 8 03:40:54 PST 2007

2007/3/8, Sebastian Trüg <strueg at mandriva.com>:
>
> 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.

Yes, I am not doubting that rdf and ontologies are the right solution for
your targets. I just think that they are too complex for what the current
aim of the wasabi project is (not that this is bad in any way).

> 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.

Yes, I was thinking along thoswe lines too.

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.

The question was raised a whle back whether we should have internationalized
keywords for searching, Ie "type:music hendrix" should be written as
"type:musik hendrix" in the Dansih locale for instance. Whether or not to
translate the actual query language like the "type" selector is another (but
related) matter. Unfortunately this has not received much discussion.

I think it would be great to have as much internationalization as possible,
but I have not given it a whole lot of thought I must admit.

> 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.

Agreed. Ideally the current apis+specs would be a subset of a full semantic
solution. If this where the case if would be easier for apps to use whatever
was available.

>
> > 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.

So I take it as you didn't find a spot-on candidate language either..?

The problems with sparql and rdfq is that they are not designed to do "fuzzy
searches" in the broader sense of the words - ie that queries match using
stemming, levenstein distance, transliterated diacritics, or word proximity,
stuff that you find in many modern indexers.

Again it would be really nice if the nepomuk query language could be a super
set of the Wasabi query language. I *think* this could be possible because
the current wasabi query language proposal is actually very close to rdfq (
http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html).

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070308/1780aec1/attachment.htm 