Hello Dominic, On Sun, Jun 23, 2013 at 09:35:53AM +0100, Dominic Oldman wrote: > I take the point about the ability to set things up quickly, but this just > points to the fact that we have some way to go on a number of strands. But we > all know we on the right path. I would say that focusing in on some of the > huge range of potential applications that you couldn't do with a relational > database will help move things along more. > > On ontology here is my experience. You need a solid ontology that describes > your domain at precisely the right level to represent domain knowledge to > establish key relationships but which supports specialisation below this > level. This level is just at the point above which the domain varies. However > after going down the specialisation route we have found a more accessible and > portable approach. > > We have used an ontology that does precisely the above but used it to create > a set of ready made constructs for key domain concepts that are > uncontentious. A particular concept may have a number of alternative > constructs from which an organisation can select as appropriate. We then > avoid the need to specialise the constructs using sub classes and sub > properties and instead provide a mechanism for plugging in local > vocabularies. This transfers the issue of co-referencing ontology extensions > to co-referencing vocabularies. This is far more accessible for two reasons. > Firstly, the contextualisation of the non-specialised elements provide enough > knowledge representation to perform the co-referencing. Secondly, there are > many vocabulary co-referencing initiatives that are becoming more mature and > accessible. The plugin approach is supported by typing whole event constructs > and reification of key properties with local terminology, people and place > authorities, but also terminology unique to the organisation (Institutional > context). > > For example, the production of something may have a generalised property of > "carried out by". This could be specialised in a large number of ways. > Instead we can look at the local specialisations and use them as a vocabulary > to either type the full event or to reify the property itself. E.g. "designed > by". > > This process avoids a whole range of issues and also has the potential to be > built into accessible implementation tools useful for organisations without > technical resources. It means that we can start producing the applications > that we can't do with relational databases and which operate across many > different datasets robustly. > > How does this sound?
This sounds complicated :-) That the cultural heritage crowd seems to have a need for it's own upper level ontology underlines my point about schematic and structural heterogeneity. Why does CIDOC define general concepts as place, event, spacial coordinates ? Are there no suitable existing ontologies for this ? Can CIDOC also be used without specialization of properties and classes ? I think museums have used controlled vocabularies for quite a while. Can you give an example that illustrates why the additional effort required for your project is justified ? Regards, Michael Brunnbauer -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail [email protected] ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
pgp0n6dOuH367.pgp
Description: PGP signature
