2007/3/8, 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;"> 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.</blockquote><div> 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).  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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.</blockquote><div> Yes, I was thinking along thoswe lines too. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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. </blockquote><div> 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.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > 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.</blockquote><div> 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.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > 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? 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.</blockquote> <div> 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.  </div>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 ( <a href="http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html">http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html</a>). Cheers, Mikkel <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.pd">http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pd </a> > >f < > > > > ><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?vi">http://svn.gnome.org/viewcvs/tracker/trunk/data/tracker-introspect.xml?vi</a> > >ew > > > > >=markup - Spotlight Metadata Spec: > > > > <a href="http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribu">http://developer.apple.com/documentation/Carbon/Reference/MetadataAttribu</a> > >te > > > > >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>