2007/3/7, Sebastian Trüg <[EMAIL PROTECTED]>:
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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
