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

[Evgeny Egorochkin]

On Thursday 31 May 2007 17:27:46 jamie wrote:
> On Thu, 2007-05-31 at 14:50 +0300, Evgeny Egorochkin wrote:
> > On Thursday 31 May 2007 12:50:24 Antoni Mylka wrote:
> > > Hello phreedom,
> > >
> > > For those of you who don't know me I'm currently working on a desktop
> > > ontology for the Nepomuk project [1] (Nepomuk Information Element
> > > Ontology). The current draft is available at [2].
> > >
> > > Overall. Mikkel Kamstrup has already noticed, that the notation used is
> > > not typical. The "Classes" are not actualy RDFS classes but "property
> > > categories". Otherwise the distinction you made between a File and
> > > Content means that these are two separate entities. Could you elaborate
> > > a bit more?
> >
> > This is a result of the limitation that only one resource can be used to
> > describe a file. There are 2 major class trees: content and source. They
> > for now are subclasses of DataObject, but this may be changed e.g. in
> > favor of DC. Each file gets assigned one content and one source class.
> > There are no conflicting deviations from RDFS, just a subset. It might be
> > more appropriate to rename Source branch to SourcedFromXXX, but I don't
> > think it's appropriate here and/or will be accepted.
> >
> > Current limitations:
> > 1) One resource per file or its equivalent like message attachment or
> > archive content.
>
> shuold be ok
>
> > 2) no multi-inheritance for classes/properties
>
> should be ok

Not so sure about it.

> > 3) RDF object is always literal. Can't directly reference resources.(has
> > workarounds).
>
> what are the workarounds?

The workaround is to specify an URI as a literal and hope software understands 
this in cases like linking archive contents.

> vCard basically needs structs (non literal resources) for things like 1
> or more contact addresses (struct of phone, email , fax etc)

If we go for structs, we get an equivalent of a full-blown RDF(s) minus 
multiinheritance.

--Evgeny