[Wasabi] Kicking of the Metadata spec - brainstorm

[Sebastian Trüg]

Hi guys,

let me finally comment on this.
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.

Cheers,
Sebastian


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