[XESAM] Ontology sketch. Feedback needed. This time with attachment.

[Evgeny Egorochkin]

On Friday 01 June 2007 11:44:02 Antoni Mylka wrote:
> Mikkel Kamstrup Erlandsen pisze:
> >  * contributor (DC)
> >  * creator (DC)
> >  * description (DC)
> >  * language (DC)
> >  * publisher (DC)
> >  * subject (DC)
> >  * title (DC)
> >  * license (an extensible vocabulary with predefined values GPL, LPGL,
> > MIT etc)
> >  * uri
> >  * category (a controled vocabulary that maps to the cats in the
> > extended onto)
>
> This particular one may be tricky. This "controlled" vocabulary should
> be extensible. I think it's not a good idea to have to agree on all
> categories at the very beginning. I would rather go for the notion of
> type. A resource may be a file, email whatever. This field would point
> at a type of a resource. (In NIE it would be expressed with rdf:type
> pointing to an URI of a class (like Document, File or whatever), in the
> simplified XESAM "language" it could point at some type identifier).
>
> The question if you want to have a simple list of types, or an
> inheritance tree of types remains open.
>
> >  * mime
> >  * creationDate
> >  * modificationDate
> >
> >
> > With this simple onto you can actually do quite a bit of nifty stuff.
> > With this in place it might also be easier to agree on extended ontology
> > as Antoni already suggested.
>
> I'm all for. With this set (or something similar) it should be possible
> to agree on a 1 to 1 mapping between NIE-core and XESAM-core.

There's already core ontology in this sense. You can consider Content and 
Source class properties as the core and AFAIK they map nicely to both NIE and 
DC. The only problemmatic cases are contact and, to a degree, Message.


> The properties from the extended part of the ontology could be mapped
> via the subproperty relations to the ones from core (as much as
> possible). A simple mechanism could realise the basic inference rule.
>
> IF a prop b AND prop subPropertyOf prop2 THEN a prop2 b
>
> This shouldn't be too difficult and time-consuming, even in systems
> where performance is a priority.

It is implemented exactly this way.

My point of concern for Nepomuk-Xesam mapping is multimedia ontology. I intend 
to discuss this on tf-ont list as soon as it's open to the public. There's no 
way to map MPEG7 for xesam, and it's not coherent(doesn't fit nicely) with 
the rest of Nepomuk ontologies. The rest is quite obvious and I don't think 
there are many extra classes/properties coming... except maybe for 
xesam-convenience onto, but those properties will be semantically irrelevant.

I'll post another onto snapshot today. 

Beagle, Recoll, Pinot: where are you guys? This ontology discussion concerns 
you, you'll have to implement it. Better start talking now :P

--Evgeny