Peristeras, Vassilios wrote:
Hello all,
I have the feeling that we are (at least partly) reinventing the wheel
here. There have been several initiatives drafting generic models and
representations for organizations. Just two examples below [1][2] which
go back to 90ies.
More generally, an in-depth look at design and data patterns literature
could also help a lot. I have the feeling that others before this group
have defined concepts like "organization", "legal entity" etc... We
could re-use their conceptual (or data or formal) models, instead of
starting the discussion from scratch.
Best regards,
Vassilios
[1] http://www.aiai.ed.ac.uk/project/enterprise/enterprise/ontology.html
[2] http://www.eil.utoronto.ca/enterprise-modelling/tove/
Both of your links point to PDFs or Postscript docs.
Are there any actual ontology doc URLs?
Kingsley
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dave Reynolds
Sent: Tuesday, June 08, 2010 11:27 AM
To: Emmanouil Batsis (Manos)
Cc: Linked Data community; [email protected]
Subject: Re: Organization ontology
On Tue, 2010-06-08 at 01:03 +0300, Emmanouil Batsis (Manos) wrote:
Sorry for jumping in. I was thinking that
a) the way i get FormalOrganization, it could as well be called
LegalEntity to be more precise.
Not quite, there are other LegalEntities that are not Organizations.
The LegalEntity notion could be made explicit:
org:FormalOrganization
subClassOf org:Organization AND ns:LegalEntity
This is better modelling because the primitive concepts are now explicit
and the nature of org:FormalOrganization as a derived concept is
clear.
I nearly did it that way but my concern was that putting LegalEntity
into org: would open up a whole can of worms about needing richer
modelling of the notion of LegalEntity (e.g. Jurisdiction etc). That
would be off topic for the focused goals and requirements for org.
b) what happens when organizations change legal status?
Pretty much any aspect of organizations change over time :) In the
context of this work there are already separate approaches to handling
versioning and change so org: defers to those. Though, in some
applications you do want to explicitly represent the historical trace of
those changes hence the inclusion of OPMV via org:ChangeEvent to give a
minimal foundation for that.
Cheers,
Dave
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
