[Wasabi] Kicking of the Metadata spec - brainstorm

Wed Mar 7 12:13:19 PST 2007

2007/3/7, Sebastian Trüg <strueg at mandriva.com>:
>
> Hi guys,
>
> let me finally comment on this.

Great to hear from you :-) I was looking forward to some Neopmuk feedback.

In the Nepomuk project we are defining metadata ontologies. This means that
> each resource (a file is also a resource but Nepomuk does not only handle
> files but all kinds of information entities on the desktop such as
> persons,
> i.e. contacts, emails, tasks, projects, or even paragraphs in a text file)
> is
> of a certain class which has a bunch of properties. The whole concept is
> of
> course inspired by the semantic web, which means that ontology definition
> and
> data storage is handled using RDF/S. Thus, classes as well as properties
> can
> be derived from other classes or properties.
> So far we defined a basic annotation NAO ontology which defines the
> following
> entities:
>
> * nao:hasAnnotation (the basic annotation relation just stating that two
>     resources are related in some way)
>   Domain: rdfs:Resource
>   Range: rdfs:Resource
>
> * nao:hasTag (tagging of resources for simple grouping, however, not
>     restricted to plain text keywords)
>   Domain: rdfs:Resource
>   Range: rdfs:Resource
>
> * nao:symbol (assign an arbitrary symbol, ie. icon to a resource, for now
>     mainly useful to assign an icon to a tag)
>   Domain: rdfs:Resource
>   Range: nie:Icon (NIE is the Nepomuk Information Entity Ontology which
> aims
>          to define basic desktop resources such as a file, an email, a
> text
>          document, an image and so on)
>
> * nao:hasRating (assign a rating to any resource)
>   Domain: rdfs:Resource
>   Range: xsd:unsignedInt
>
> * nao:Tag (the most simple variant of a tag)
>     rdfs:label is used to assing a string keyword to the tag, hasSymbol
> can be
>     used to assign an icon.
>
> These are the basic properties of NAO but not all. I just listed them to
> give
> you an idea of how we think it could be done.
>
> The idea is to use XML schema types for literals, i.e. values that are not
> resources. Localization support is already provided by RDF/S itself, thus
> the
> ontologies can contain localized names and comments (ie. descriptions
> which
> can be used in the GUI) for all classes and properties and also the
> metadata
> values themselves can be localized.
>
> As already mentioned there also is the NIE ontology which defines all the
> basic desktop resources. I will talk about that later.
>
> The nice thing is that additional metadata types and properties can be
> introduced by anyone. I propose a standardized method of storing these
> ontologies. For example some xdg folder which contains the ontologies or
> each
> ontology has a desktop file defining its contents. Then the metadata types
> are well defined and can be used by any application or framework.
>
> Just to get our ideas in the mix,
> please comment.

Will do.

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

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

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.

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?

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.pdf
> <
> >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?view
> >=markup - Spotlight Metadata Spec:
> >
> http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribute
> >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/20070307/0890a713/attachment.htm 