ext Sw Fan wrote:
> Hi Urho,
>
> Thanks for your explanation!
>
> You said that the headers of sender, to and cc are redundant and could 
> be dropped, is my understanding right? But why not have the contact 
> instances (see below) dropped instead? So I still don't see how 
> creating Contact instances for every from/to/cc field makes any sense. 
> Can you shed light on that? Thanks for your effort!
Actually, the correct way of mapping the headers, would result in such, 
that for the cc field, you would have a one string value containing the 
entire cc list of all people and the full name in <>. The header in 
Nepomuk nmo:Email is intended to follow the Email standard in notation, 
thus, you can check the potential email header fields from:
http://tools.ietf.org/html/draft-resnick-2822upd-06

Thus, it would not be possible to use that in any linking whatsoever. 
So, it's even worse solution than using the Contact object as the Email 
to PersonContact linker.

Also, please note that in this case, you would DEFINITELY be creating a 
new node for each header field. This is unlike in the Contact approach, 
where, if you do:
 IF CONTACT EMAIL EXISTS:
    only link to the Contact, instead of creating always a new one.


As I see it, we could solve this by any of the following three options:
1. Use is as it is (not a treat for the eyes, but works).
2. Create a new class to handle all message linkings and have a proper 
name for it (requires changes and breaks compatibility with the current 
Nepomuk)
3. Go one step further and link the cc, to, from and bcc directly to 
EmailAddress and add a new literal to the EmailAddress (fullname). This 
will result  in slight loss of data for the fullname part when people 
change their names. I do not think that is an issue to be honest, as 
usually in most of the applications the fullname part is anyway taken 
from addressbooks. However, I can totally see counter arguments against 
this as well. This would also be doing much more direct mapping of 
emails to contacts. This approach breaks compatibility. There is also 
alternative version of this approach defined in the ticket, recomended 
by Juerg Billeter. It also breaks compatibility.


I tend to lean towards solution 1., but at the same time, the solution 
3. would probably be the most efficient to use for any storage/query 
engine.

Kind regards,
Urho

>
> {{
> <urn:uuid:[email protected] 
> <mailto:[email protected]>> a nco:Contact;
>   nco:fullname "Darron Davison duisaliquam WORK ACCOUNT ";
>   nco:emailAddress "[email protected] 
> <mailto:[email protected]>".
> <urn:uuid:[email protected] <mailto:[email protected]>> a nco:Contact;
>   nco:fullname "Me Myself";
>   nco:hasEmailAddress <mailto:[email protected] <mailto:[email protected]>>.
> <urn:uuid:[email protected] 
> <mailto:[email protected]>> a nco:Contact;
>   nco:hasEmailAddress <mailto:[email protected] 
> <mailto:[email protected]>>.
> }}
>
> Best,
> Mark
>
>
> ------------------------------------------------------------------------
> *From:* Urho Konttori <[email protected]>
> *To:* ext Sw Fan <[email protected]>
> *Cc:* Leo Sauermann <[email protected]>; Ivan Frade 
> <[email protected]>; [email protected]
> *Sent:* Thursday, January 22, 2009 4:17:52 PM
> *Subject:* Re: [people] (no subject)
>
> Hi Mark,
>
> I'll just comment in quickly. The model is not aesthetically pleasing, 
> but it works.
>
> Once you drop Leos assumption that a new nco:Contact has to be made 
> for every single instance of to, from, cc, bcc or every email, and, 
> instead, modify it to only create those in case the email address does 
> not exist, the model will not be really replicating that much datat. 
> It will not make intuitive sense at any point, especially with the 
> PersonContact being a subclass of Contact, which is really confusing 
> me a lot, but the model does work, so it's hard to say it's a bug in 
> the ontology structure, it's much more of a problem in naming 
> convention, and perhaps the inheritance of that class, so, I do agree 
> with you totally Mark, but I do see Leos point. Here is an example:
>
> I first define 2 person contacts, me and darron and email addresses 
> for both. then I define the contacts related to the email, and then 
> the email object. Now, the link between PersonContacts and the Contact 
> objects will of course happen through the EmailAddress object (or the 
> uris). Notice that Darron has a different name in his Contact instance 
> than in his personcontact instance. I also added cc contact that 
> doesn't even have a name, nor a personcontact.
>
> The email has now headers that cover sender, to and cc, but these are 
> redundant with the contact mapping, so they could indeed be dropped.
>
>
> <mailto:[email protected] <mailto:[email protected]>> a nco:EmailAddress;
>   nco:emailAddress "[email protected] <mailto:[email protected]>".
>
> <urn:uuid:1> a nco:PersonContact;
>   nco:fullname "Me Myself";
>   nco:nameGiven "Me";
>   nco:nameFamily "Myself";
>   nco:birthDate "2008-01-01";
>   nco:hasEmailAddress <mailto:[email protected] <mailto:[email protected]>>.
>
>
>
> <mailto:[email protected] 
> <mailto:[email protected]>> a nco:EmailAddress;
>   nco:emailAddress "[email protected] 
> <mailto:[email protected]>".
>
> <mailto:[email protected] 
> <mailto:[email protected]>> a nco:EmailAddress;
>   nco:emailAddress "[email protected] 
> <mailto:[email protected]>".
>
> <urn:uuid:1629001709> a nco:PersonContact;
>   nco:fullname "Darron Davison";
>   nco:nameGiven "Darron";
>   nco:nameFamily "Davison";
>   nco:birthDate "1930-01-04";
>   nco:title "Sales Representative Computers";
>   nco:hasEmailAddress <mailto:[email protected] 
> <mailto:[email protected]>>;
>   nco:hasEmailAddress <mailto:[email protected] 
> <mailto:[email protected]>>;
>   nco:hasPhoneNumber <tel:+14849562430>;
>   nco:hasPostalAddress <urn:uuid:2118792036>.
>
>
> <urn:uuid:[email protected] 
> <mailto:[email protected]>> a nco:Contact;
>   nco:fullname "Darron Davison duisaliquam WORK ACCOUNT ";
>   nco:emailAddress "[email protected] 
> <mailto:[email protected]>".
>
> <urn:uuid:[email protected] <mailto:[email protected]>> a nco:Contact;
>   nco:fullname "Me Myself";
>   nco:hasEmailAddress <mailto:[email protected] <mailto:[email protected]>>.
>
>
> <urn:uuid:[email protected] 
> <mailto:[email protected]>> a nco:Contact;
>   nco:hasEmailAddress <mailto:[email protected] 
> <mailto:[email protected]>>.
>
>
> <urn:uuid:597366485> a nmo:Email;
>   nmo:to <urn:uuid:[email protected] <mailto:[email protected]>>;
>   nmo:from <urn:uuid:[email protected] 
> <mailto:[email protected]>>;
>   nmo:cc <urn:uuid:[email protected] 
> <mailto:[email protected]>>;
>   nmo:sentDate "2008-10-20T15:28:21";
>   nmo:receivedDate "2008-10-20T15:28:59";
>   nmo:contentMimeType "text/plain";
>   nmo:messageHeader [nmo:headerName "User-Agent"; nmo:headerValue 
> "tin/unoff-1.3-BETA-970813 (UNIX) (Linux/2.0.30 (i486)) "];
>   nmo:messageHeader [nmo:headerName "from"; nmo:headerValue 
> "[email protected] <mailto:[email protected]>"];
>   nmo:messageHeader [nmo:headerName "to"; nmo:headerValue "[email protected] 
> <mailto:[email protected]>"];
>   nmo:messageHeader [nmo:headerName "cc"; nmo:headerValue 
> "[email protected] 
> <mailto:[email protected]>"];
>   nmo:messageSubject "Commodoconsequat tationullamcorper in feugait 
> hendrerit te duis te aliquam lobortis. ";
>   nmo:plainTextMessageContent "Nibh nostrud eum nonummy facilisis ex 
> tincidunt praesent delenit facilisis veniam ad facilisi exerci. Nulla 
> nonummy at eufeugiat nulla diam. Vel amet feugiat consequat amet minim 
> vel iusto feugiat sit at blandit veniamquis ullamcorper. Facilisi erat 
> in feugait ad. Doloremagna Utwisi iriure feugait eros blandit delenit 
> dolore delenit facilisi commodoconsequat consectetuer. "..
>
>
>
> > Dear Ivan & Leo,
> >
> > Thanks for your replies! I read the comment by Leo for the ticket 
> #698 (http://dev.nepomuk.semanticdesktop.org/ticket/698), but I still 
> don't understand why a new nco:Contact instance should be created for 
> each email's from field.
> >
> > I thought we use RDF to get data entities connected, eliminating 
> dupliated and siloed data and building a web of data. Isn't it?
> >
> > However, I don't see this can be achieved by creating fresh 
> nco:Contact instances for every email's "from" field. So why bother 
> transforming the raw data into RDF?
> >
> > Thanks!
> >
> > Best,
> > Mark
> >
> > ------------------------------------------------------------------------
> > *From:* Leo Sauermann <[email protected] 
> <mailto:[email protected]>>
> > *To:* Ivan Frade <[email protected] <mailto:[email protected]>>
> > *Cc:* ext Sw Fan <[email protected] <mailto:[email protected]>>; 
> [email protected] <mailto:[email protected]>
> > *Sent:* Wednesday, January 21, 2009 11:43:48 PM
> > *Subject:* Re: [people] (no subject)
> >
> > The short answer is:
> >
> > create fresh nco:Contact instances for every email's "from" field to 
> represent mails thouroughly.
> >
> > best
> > Leo
> >
> > It was Ivan Frade who said at the right time 21.01.2009 09:10 the 
> following words:
> >> Hi Mark,
> >>
> >>  You are not the only one with that problem. There is ticket open about
> >> that issue with an interesting discussion:
> >>
> >> http://dev.nepomuk.semanticdesktop.org/ticket/698
> >>
> >>  Regards,
> >>
> >> Ivan
> >>
> >> El mar, 20-01-2009 a las 23:40 -0800, ext Sw Fan escribió:
> >> 
> >>> Hi all,  I was investigating the Nepomuk ontologies these days, 
> and I found out
> >>> that, in NMO, the property from was defined with domain as
> >>> nmo:Message and range as nco:Contact.  I wonder why the range of from
> >>> was defined as Contact, instead of EmailAddress, since a given Contact
> >>> can have more than one email addresses. So based on the constraint
> >>> imposed by the ontology, one will not be able to tell which email
> >>> address (suppose he has more than one) was used by the contact to send
> >>> the message.  Anything I missed in this context?  Thanks for your 
> clarification!
> >>>  Cheers,
> >>> Mark
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> people mailing list
> >>> [email protected] <mailto:[email protected]>
> >>> http://lists.semanticdesktop.org/mailman/listinfo/people
> >>>   
> >> _______________________________________________
> >> people mailing list
> >> [email protected] <mailto:[email protected]>
> >> http://lists.semanticdesktop.org/mailman/listinfo/people
> >>
> >> 
> >
> >
> > -- ____________________________________________________
> > DI Leo Sauermann      http://www.dfki..de/~sauermann 
> <http://www.dfki.de/%7Esauermann>
> > 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:  [email protected] 
> <mailto:[email protected]>
> >
> > 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
> > ____________________________________________________
> > 
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > people mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.semanticdesktop.org/mailman/listinfo/people
> > 
>
>

_______________________________________________
people mailing list
[email protected]
http://lists.semanticdesktop.org/mailman/listinfo/people

Reply via email to