W3C home > Mailing lists > Public > semantic-web@w3.org > October 2013

AW: vCard Ontology MD questions

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>
Message-ID: <F92C45C191C9FB4281F352EB52DFA7AD085CDCA0@PMXMDB02.pk.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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:35 UTC