information-artifact-ontology / IAO

information artifact ontology
Creative Commons Attribution 4.0 International
70 stars 25 forks source link

definition of "email address" #188

Open Public-Health-Bioinformatics opened 7 years ago

Public-Health-Bioinformatics commented 7 years ago

Could that be finalized? Looking at the original thread, with Allan Ruttenberg's proposal: https://code.google.com/archive/p/information-artifact-ontology/issues/130 I throw this on the table: "An email address is a textual entity which is a local or internet network-resolvable identifier used for sending messages to a personal or organizational email account or message handler on an email server. It may also be used appropriately or illegitimately as an identification token in authentication or messaging processes."

alanruttenberg commented 7 years ago

Thank you for your offer of a definition.

I'm not sure that I would classify an email address as a textual entity, but part of that is that I don't think textual entity is defined clearly enough, and in such a way as to not lead to the need for asserted multiple inheritance. So the first question I would ask is whether further specifying that it is a textual entity, or leaving it as it is, a sibling which is not declared disjoint, would have consequence for your application.

I'm also not sure that the specification of what it might be used for should be part of the definition, as the definition should cover all instances.

Another candidate for parent would be CRID, with an understanding that email addresses are about (at least) something like foaf:mbox. An argument against it being a CRID might be that while certain email addresses are centrally registers, not all are, for example gmail email addresses modified by adding "+xxxx" to the username part, every case of which is interpreted, for the purposes of email delivery, to be addressed to the same thing the email address without the "+xxx".

To capture the use of email address as authentication, see d-acts authentication. A plausible strategy would be to define a subclass of authentication which is authentication using an email address. You might engage the developers on the question of whether it needs to be the case that only documents(or rather their bearers) can have a credential role, as it would generally be agreed that an email address is a document.

There are a great many things that could use better definitions in IAO, and there are efforts towards a revision that might address them, but it is not here now. As a practical matter, does something in an application you have in mind hinge on better specifying email address?

alanruttenberg commented 7 years ago

I started an issue about how email and password are used as authentication at the d-acts project

Public-Health-Bioinformatics commented 7 years ago

Ok, it will be some time before I can dive into the d-acts framework properly. But briefly, pursuing a definition for email address is more of a housekeeping academic exercise for our GenEpiO ontology (nothing really hinges on it), where I had positioned it under IAO_0000577 CRID rather than have it directly under IAO_0000030 Information Content Entity, which I find is too high level a home for it. I agree it should have a CRID home!

screen shot 2016-10-25 at 8 08 31 pm

"email address" is a good case of an entity being able to perform a different role in different processes; as an authentication token on the one hand (where a CRID can be a particular website user database), or as a token in a network transport protocol (mail) on the other, where it actually holds two separate CRIDS, one for DNS, the other for mailserver user (with all sorts of possible aliasing mechanisms which nevertheless map to one or more targets).

Also, I have called email address a textual entity in order to set it up as a candidate for parsing [user]@[domain] . In fact I have annotated it with the specific string validation regular expression that current internet mail protocol allows for. One could argue that the existence of a specific format for this textual entity is its minimal semantics, and place intentionality-driven definitions about its usage as subclass "sensu" definitions, e.g. email address (sensu authentication token) or ... (sensu email transport address)

mcourtot commented 7 years ago

Hi @ddooley - if you're interested we could add you to the IAO repo, and you could move forward with PRs? It'd be good to have a starting point/URI for the terms I think.

Public-Health-Bioinformatics commented 7 years ago

Sure, that would be a good exercise for me in getting experience in the feedback loop of community curation! Thanks.

mcourtot commented 7 years ago

ok - you should now have access, any problem please let us know!

Public-Health-Bioinformatics commented 7 years ago

So, just to be clear, I've forked IAO, and can make my changes to email, and move it in hierarchy, and add subordinate email (sensu ...) entries, and then make a PR. Ok?

mcourtot commented 7 years ago

Sounds good to me! Maybe add one or two first just to make sure we are on the same page and once 'validated' you could then add other classes following the same model? I'm not sure which entries exactly you're planning to add, but I wouldn't want you to spend the time doing it all and then having to update it all again for a small technicality for example...

alanruttenberg commented 7 years ago

Pull requests don't work very well because the order of triples can change between saves. So if any edit is fine on the owl file between when the pr is made and when it is merged, the diff is useless. If you are developing new terms you could dev then as a file to import, and then it is easy for a committer to use a text editor to add them to the main file. Or I can add you as a committer and you can edit directly.

Public-Health-Bioinformatics commented 7 years ago

I suspected that would be a problem of the owl file. I will do the import approach.

There is a solution to the triple order change issue - to add an XML/RDF deterministic sort of the contents of the owl file on/after save. I'll see if that's workable in my own GenEpiO realm; it would simplify community editing of GenEpiO etc.

mcourtot commented 7 years ago

Looking at the current editing rate of the IAO OWL file I didn't really anticipate an issue ;)

If you're looking at serializing in specific order maybe talk to @cmungall. I think it's an overkill for this use case but YMMV.

jamesaoverton commented 7 years ago

Recent OWLAPI (and thus Protege) saves XML in deterministic order, so it will work better with version control and PRs. I think this is the relevant issue:

https://github.com/owlcs/owlapi/issues/273

You still have to read the XML and numeric IDs.

Public-Health-Bioinformatics commented 7 years ago

Cool! I threw a few questions over there. Heh, Melanie I didn't know "YMMV", thx for new lingo.

alanruttenberg commented 7 years ago

@mcourtot goes both ways - either his or repo change order. However if they do as James says, it shouldn't be an issue. :-P

Still, I think that the import method is cleanest - easy to do, easy to review.