2007/3/7, Sebastian Trüg <<a href="mailto:strueg@mandriva.com">strueg@mandriva.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi guys, let me finally comment on this.</blockquote><div> Great to hear from you :-) I was looking forward to some Neopmuk feedback. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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 (<a href="http://wiki.freedesktop.org/wiki/WasabiQueryLanguage">http://wiki.freedesktop.org/wiki/WasabiQueryLanguage</a>) 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 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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: > <a href="http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf"> http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf</a>< ><a href="http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec">http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec </a>> - Shared > Metadata Spec: > <a href="http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadata_2dspec">http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadata_2dspec</a> >  - Tracker metadata api: > <a href="http://svn.gnome.org/viewcvs/tracker/trunk/data/tracker-introspect.xml?view">http://svn.gnome.org/viewcvs/tracker/trunk/data/tracker-introspect.xml?view</a> >=markup - Spotlight Metadata Spec: > <a href="http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribute">http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribute</a> >sRef/Reference/CommonAttrs.html > >  - Shared Emblem Spec: > <a href="http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec">http://freedesktop.org/wiki/Standards_2fdesktop_2demblem_2dspec</a> >  - 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 <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg"> http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>