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

[Evgeny Egorochkin]

On Wednesday 30 May 2007 23:54:28 Mikkel Kamstrup Erlandsen wrote:
> 2007/5/30, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > Sorry forgot the most important part :)
> >
> > ----------------
> >
> >
> > Hi all,
> >
> > I'd like you to take a look at the ontology sketch
> >
> > http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&t
> >arget=viz.png
>
> Thanks for the effort. I like the big picture. As always the devil is in
> the details :-)
>
> Just to avoid confusion:
>  * Solid blue arrows = "is a child category of"
>  * Dashed blue arrow = "is a child field of"
>  * Purple arrow = "Field belongs to category"
>
> Points of interest:
> > *** Sources
> >         *Source hierarchy
> >         *Which properties belong to content and which to source?
> >
> > *** Multimedia ontology
>
> I think it would be good to able to differentiate between photos and other
> imagery. Visual cat can't be used for this since you would get videos under
> here too...

Agree. Will add Image class.

> *** Contact ontology
>
>
> Do you have anything here, or is this just blank so far? Anyway I see that
> this can be tricky given that we want to support many protocols and home-,
> work-, and -mobile accounts (and be extensible as well). Here's aproposal:
>
> Contact.FullName
> Contact.Name
> Contact.MiddleName
> Contact.Surname
> Contact.Nickname
>
> Contact.Nickname.<protocol> --> Contact.Nickname (screen name)
> Contact.Account.<protocol>  --> Contact.Account (email address, msn login
> etc)
>
> And a set of predefined protocols such as Phone.Home,Phone.Work,
> Email.,EmailJabber,IRC,MSN,Yahoo, etc. Fields such as
> Contact.Account.Phone.Home would derive from Contact.Account.Phone.
>
> This gets a little many-fielded but I fail to see how we can make it
> simpler.

Without multiple-node descriptions, you can't. I might for now include a small 
part of the onto structured like this, just as an example, not to clutter the 
graph.


> *** Corner cases:
> >         * Complex file formats like databases, mailboxes.
> >         * Problematic classes like Source code.
> >
> > *** DataObject properties
> >         These are the most generic ones. We need to decide whether
> > DataObject
> > implements DC or DC is placed one level lower.
>
> I don't think that it makes sense to have (full) DC on DataObjects. Fx what
> is the dc:subject of an IRC-log? Maybe a subset of DC can go here...

Email doesn't have a description, license etc as well. Remember, it's the most 
generic description. Fields that don't apply, don't get included.

The issue here is that we need e.g. a keyword list incorporating both 
content-embedded and user-provided keywords. We may have a generic DataObject 
class for this, or we may map this directly to DC. Personally I prefer having 
custom DataObject for consistency. i.e. Xesam apps can use Xesam core onto 
and not care about anything else.

> Speaking about DC I think (as has also been discussed in the past) that DC
> fields should be "abstract" in the sense that you can't assign values to
> them.

This is in implementation's hands to enforce this. I don't mind putting this 
restriction in the spec.

> *** Document
> Document.Layout = {portrait,landscape}
> Document.PaperType = {A4,A5,Letter, etc}

Good suggestions. However remember we have to index txt and html among the 
others. Though I don't think that without multiple-inheritance you can get 
away without too many generic optional properties.

> *** Property interitance:
> >         As you may have noticed, there's no sent/recv date for messages
> > and other
> > obvious fields are missing.
>
> <SNIP>
>
> > For Email case, sent time = content creation time;
> > recv time = local copy ceation time(File creation time as repoted by the
> > FS)
>
> Ok. If we do things  like this these things have to be *clearly* specced
> out somewhere.

For now, there's no other option, otherwise the graph gets cluttered. As to 
the final spec, I'd like to have an argumented objection to my criterias for 
subproperties. We need motivated decisions.

If there's no agreement on this, we can opt for Xesam core+Xesam conveniece 
ontologies. Xesam core implements the full functionality. Xesam convenience 
implements external ontology mappings and convenient(but semantically 
irrelevant) field renames,.

--Evgeny