- From: Klee, Carsten <Carsten.Klee@sbb.spk-berlin.de>
- Date: Tue, 29 Oct 2013 09:16:18 +0000
- To: 'Marcel Fröhlich' <mfroehlich@brox.de>
- CC: "semantic-web@w3.org" <semantic-web@w3.org>, "Heise, Andreas" <Andreas.Heise@sbb.spk-berlin.de>, "'Adrian Pohl' (pohl@hbz-nrw.de)" <pohl@hbz-nrw.de>, "voss@gbv.de" <voss@gbv.de>, "Rolschewski, Johann" <Johann.Rolschewski@sbb.spk-berlin.de>
Hi Marcel! Thanks for your response. > My understanding is that the organization ontology has different groups of > elements to model different aspects > (org structure, org history/provenance, location info, reporting > structure). > The way you plan to do it, somehow mixes up the aspect of location with > the aspect of organizational roles and org structure. > Maybe you could think of OrganizationalUnits rather than only Sites in > your model. The Site class is meant for the location aspect only. > Why model organizational roles on the level of business card information > (inside vcard namespace)? > The organization ontology has a neat set of primitives to model roles > within the org namespace. The roles I meant are not organizational roles but roles for 'contact points', which are (not always) bound to locations in our database. Maybe my abstract example is not precise enough. I wanted to keep it very simple. While our database is not that simple, I'm planning to differ from organizational structure and locations (sites) whenever it is possible. Our address databases [1] model doesn't really fit into the clearer model of the Organization Ontology, because we have records for organizations [2], we have records for organizational units [3], we have records for sites [4] and we have also records for agents (like a database [5]). All have addresses (even the databases) and contact information, which makes it very difficult to differentiate between organizational structure, location and roles. > On the other hand, I understand that you are already happy with the > solution you found :-) Well there will be some impreciseness like you expect. Hugh Glaser pointed out that these pieces of information must be retrievable with SPARQL otherwise they are not very useful. I will keep this in mind... Cheers! Carsten [1] <http://sigel.staatsbibliothek-berlin.de/en/suche/> [2] <http://sigel.staatsbibliothek-berlin.de/en/suche/?isil=DE-188> [3] <http://sigel.staatsbibliothek-berlin.de/en/suche/?isil=DE-188-920> [4] <http://sigel.staatsbibliothek-berlin.de/en/suche/?isil=DE-1a> [5] <http://sigel.staatsbibliothek-berlin.de/en/suche/?isil=ZDB-28-OHY> > $orgOrSite > vcard:hasAddress $addr ; > vcard:hasEmail $email1, $email2, $email3 ; > vcard:hasTelephone $telephone1, $telephone2, $telephone3 . > vcard:hasRelated $contact3 . > > $addr > vcard:hasRelated $email1, $email2, $telephone1, $telephone2, > $contact1, $contact2 . > > $email1 > $telephone1 > vcard:hasRole $contact1 . > > $email2 > $telephone2 > vcard:hasRole $contact2 . > > $email3 > $telephone3 > vcard:hasRole $contact3 . > > $contact1 > dc:description "contact1 info" ; > vcard:role "role1" . > > $contact2 > dc:description "contact2 info" . > vcard:role "role2" . > > $contact3 > dc:description "contact3 info" . > vcard:role "role3" . > > Now all telephone numbers and email addresses can be queried directly for > $orgOrSite and the hierarchy and the roles are also represented. > > Cheers! > > Carsten >
Received on Tuesday, 29 October 2013 09:16:47 UTC