Re: [Fwd: Re: [Fwd: Re: Nepomuk message ontology - questions from implementor point of view]]
Hi Philip,
NMO was designed to represent the structure of MIME for indexing,
searching, and annotating e-mails.
For that it worked quite well.
To program an e-mail client that stores its contents solely in a
proprietary format (such as Microsoft Outlook does)
we would indeed need to change a few bits of the ontology.
If this is really your purpose and you need to meet a deadline, then we
should go on with this discussion,
and I would encourage you to suggest changes to NMO and to join OSCAF,
instead of making
your own ontology
If making your own ontology, you have to write, document, publish, and
maintain for the next years,
and explain it to developers.
If you just need NMO for indexing and search, I would say that the
structure worked well as-is
for our existing projects.
So, we are open for changes! please give constructive change requests,
OSCAF will regularly publish new versions of NMO.
From my experience I add:
note that binary content is not a friend of RDF,
so I doubt that MIME can be completly and losslessly expressed in RDF
in an "elegant" way,
but I am also not that deep into E-Mail handling than you, so we need
your input here!
best
Leo
It was Philip Van Hoof who said at the right time 14.01.2009 13:04 the
following words:
On Wed, 2009-01-14 at 09:49 +0200, Urho Konttori wrote:
Philip, did you have issues with the mno classes which haven't been
mentioned yet?
The biggest problem that I have with MNO is that it doesn't represent
the structure of MIME. Which is, in the end, what all E-mails are
nowadays.
In MIME there's no flat "Message" type, there are only MIME parts that
can contain other MIME parts. The root MIME part of what people refer to
as an "E-mail" is also a MIME part by itself, just like all others.
Another thing I noticed is that "nmo:contentMimeType" in NMO is a flat
xsd:string. In reality is "Content-Type" in MIME, however, at least two
keys and two values: Content-Type itself, charset, but also boundary is
an important component of the Content-Type and nearly always used.
These values are vital 'meta' information for any E-mail client
developer to have. To display the E-mail you need them.
I'm a bit like: "hmm, so if I were to use NMO for any kind of E-mail
client, then I would have to make a new ontology on top of NMO". The
ontology would a) change the structure drastically and b) needs to add
vitally important predicates.
The b) item, would for me be okay. The a) item for me means that I wont
use NMO for my E-mail client. As if I were to develop one with NMO's
structural incompatibilities with what real E-mails are, then I would
have to concentrate almost solely on workarounds for this.
An example (just look at the source of any FWD E-mail):
Root message (you consider this as a message/rfc822) {
Content-Type: multipart/mixed;
boundary="7078..-YXEDb5ZdVDS8kavaDZJKd9YlUri2LIB8@public.gmane.org" {
--7078..peirce.dave.cridland.net
Content-Type: text/plain; delsp="yes"; charset="us-ascii";
format="flowed"
[TEXT]
--7078..-YXEDb5ZdVDS8kavaDZJKd9YlUri2LIB8@public.gmane.org
Content-Disposition: inline
Content-Type: message/rfc822 {
Return-Path: <owner-ietf-imapext-0n0DUYAvMAtg9hUCZPvPmw@public.gmane.org>
...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
[TEXT]
}
}
}
In programming I usually structure it more or less like this:
class HeaderValue {
string [] parts;
}
class HeaderPair {
string name;
HeaderValue value;
}
class ContentType {
ContentType (HeaderPair header) {
...
}
}
class MimePart {
HeaderPair [] headers;
MimePart [] children;
}
class Message extends MimePart {
string get_from () {
return headers["from"].value.parts[0];
}
ContentType get_type() {
return new ContentType (headers["Content-Type"]);
}
etc
}
A good example of a library that does it more or less this way is GMime,
by the way: http://spruce.sourceforge.net/gmime/
--
____________________________________________________
DI Leo Sauermann
http://www.dfki.de/~sauermann
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail:
leo.sauermann-7kGu3w2zD6I@public.gmane.org
Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________
<div>
Hi Philip,<br><br>
NMO was designed to represent the structure of MIME for indexing,
searching, and annotating e-mails.<br>
For that it worked quite well. <br><br>
To program an e-mail client that stores its contents solely in a
proprietary format (such as Microsoft Outlook does)<br>
we would indeed need to change a few bits of the ontology.<br><br>
If this is really your purpose and you need to meet a deadline, then we
should go on with this discussion,<br>
and I would encourage you to suggest changes to NMO and to join OSCAF,
instead of making<br>
your own ontology <br>
If making your own ontology, you have to write, document, publish, and
maintain for the next years,<br>
and explain it to developers. <br><br>
If you just need NMO for indexing and search, I would say that the
structure worked well as-is<br>
for our existing projects.<br><br>
So, we are open for changes! please give constructive change requests,<br>
OSCAF will regularly publish new versions of NMO.<br><br>
From my experience I add:<br>
note that binary content is not a friend of RDF,<br>
so I doubt that MIME can be completly and losslessly expressed in RDF
in an "elegant" way,<br>
but I am also not that deep into E-Mail handling than you, so we need
your input here!<br><br>
best<br>
Leo<br><br><br><br>
It was Philip Van Hoof who said at the right time 14.01.2009 13:04 the
following words:
<blockquote cite="mid:1231934688.12336.38.camel <at> tinc" type="cite">
On Wed, 2009-01-14 at 09:49 +0200, Urho Konttori wrote:
<blockquote type="cite">
Philip, did you have issues with the mno classes which haven't been
mentioned yet?
</blockquote>
The biggest problem that I have with MNO is that it doesn't represent
the structure of MIME. Which is, in the end, what all E-mails are
nowadays.
In MIME there's no flat "Message" type, there are only MIME parts that
can contain other MIME parts. The root MIME part of what people refer to
as an "E-mail" is also a MIME part by itself, just like all others.
Another thing I noticed is that "nmo:contentMimeType" in NMO is a flat
xsd:string. In reality is "Content-Type" in MIME, however, at least two
keys and two values: Content-Type itself, charset, but also boundary is
an important component of the Content-Type and nearly always used.
These values are vital 'meta' information for any E-mail client
developer to have. To display the E-mail you need them.
I'm a bit like: "hmm, so if I were to use NMO for any kind of E-mail
client, then I would have to make a new ontology on top of NMO". The
ontology would a) change the structure drastically and b) needs to add
vitally important predicates.
The b) item, would for me be okay. The a) item for me means that I wont
use NMO for my E-mail client. As if I were to develop one with NMO's
structural incompatibilities with what real E-mails are, then I would
have to concentrate almost solely on workarounds for this.
An example (just look at the source of any FWD E-mail):
Root message (you consider this as a message/rfc822) {
Content-Type: multipart/mixed;
boundary=<a class="moz-txt-link-rfc2396E" href="mailto:7078..@...">"7078..@..."</a> {
--7078..peirce.dave.cridland.net
Content-Type: text/plain; delsp="yes"; charset="us-ascii";
format="flowed"
[TEXT]
--7078..@...
Content-Disposition: inline
Content-Type: message/rfc822 {
Return-Path: <a class="moz-txt-link-rfc2396E" href="mailto:owner-ietf-imapext@..."><owner-ietf-imapext@...></a>
...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
[TEXT]
}
}
}
In programming I usually structure it more or less like this:
class HeaderValue {
string [] parts;
}
class HeaderPair {
string name;
HeaderValue value;
}
class ContentType {
ContentType (HeaderPair header) {
...
}
}
class MimePart {
HeaderPair [] headers;
MimePart [] children;
}
class Message extends MimePart {
string get_from () {
return headers["from"].value.parts[0];
}
ContentType get_type() {
return new ContentType (headers["Content-Type"]);
}
etc
}
A good example of a library that does it more or less this way is GMime,
by the way: <a class="moz-txt-link-freetext" href="http://spruce.sourceforge.net/gmime/">http://spruce.sourceforge.net/gmime/</a>
</blockquote>
<br><br>--
____________________________________________________
DI Leo Sauermann <a class="moz-txt-link-freetext" href="http://www.dfki.de/~sauermann">http://www.dfki.de/~sauermann</a>
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail: <a class="moz-txt-link-abbreviated" href="mailto:leo.sauermann@...">leo.sauermann@...</a>
Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________
</div>
RSS Feed