ontology-summit
[Top] [All Lists]

Re: [ontology-summit] [ReusableContent] Reuse of Linked Data vis-a-vis R

To: Ontology Summit 2014 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Gary Berg-Cross <gbergcross@xxxxxxxxx>
Date: Wed, 29 Jan 2014 09:56:28 -0500
Message-id: <CAMhe4f26H7fSwFFkn5Wkz_jZs3u3HEuo+61WM-nCxnFq02RmhQ@xxxxxxxxxxxxxx>
I have tended to think (perhaps lazily) of modular ontologies as things like the upper-level Semantic Web for Earth and Environmental Terminology (SWEET) developed  by Raskin ar NASA’s Jet Propulsion lab for Earth system science (http://sweet.jpl.nasa.gov/ontology/). These are really mostly subject areas, they call realms,  as it says on their site:
 SWEET 2.2 is highly modular with 6000 concepts in 200 separate ontologies. 

But they do have
modules on Representation, State, Matter, Quantity etc.

And it might be worth mentioning that there was an  "attempt" at making some new construction easier by a facet approach.

The large  SWEET ontology collection of concepts and terms, is divided into orthogonal dimensions or facets  (http://sweet.jpl.nasa.gov/guide.doc). I'm not sure I buy this simplification of independent/orthogonal  concepts but they tried a faceted design using combinations of terms across ontologies in order to make  compound terms with compound meaning. An example I saw in:
 
Tripathi, Ajay, "Developing a Modular Hydrogeology Ontology Extending the Sweet Ontologies" (2005). Geosciences Theses. Paper 3.

 was a term air in one of the ontology modules  and another term temperature in the same or other SWEET ontology, we can combine the two terms to make a  compound term "air temperature". 
of course not all concepts add so simply...

Gary Berg-Cross, Ph.D.  
NSF INTEROP Project  
SOCoP Executive Secretary
Knowledge Strategies    
Potomac, MD
240-426-0770


On Tue, Jan 28, 2014 at 9:03 PM, Andrea Westerinen <arwesterinen@xxxxxxxxx> wrote:
Matthew, My apologies for the delay in answering, but I was travelling and unable to respond.  

My replies are inline ...

Andrea


On Sun, Jan 26, 2014 at 2:52 AM, Matthew West <dr.matthew.west@xxxxxxxxx> wrote:

Dear Andrea,

 

You wrote:

 

I do recognize that a lot of work went into FIBO to create smaller, more reusable content.  In fact, that was one of the positives that I highlighted in my presentation yesterday [1].  It was straightforward to find concepts and the annotation was amazing!

 

But, I did find that for many of the more "advanced" topics, there were imports of most of the FIBO Foundational Ontology. For example, People.rdf imported Organizations (and FormalOrganizations), Locations (and Countries and Addresses), Goals, etc.  So, the more interesting topic ended up being rather "inclusive."

 

Might there be a way to modularize this even more?

 

 

I’m wondering if you are chasing your tail here, but I’m also not sure if I understand exactly what you are proposing. So let me start by asking: what size do you think a module should be?


There are two different ways to answer this depending on your definition of a "module".  When I think of a module, I think of a semantic concept, a definitional element, with a description of its design, uses and the context in which it was developed.  It is by no means a complete/integrated data model.   

 

If I look at my own experience, we opted to make ISO 15926-2 an integrated data model. It is only 200 entity types, so it is not very large, and we could have modularized it. However, we considered this rather pointless, not because the modules were tightly bound together, but that to do anything significant you had to use most of what would have been the core modules.


Agree.  To model a domain, process, etc. requires multiple semantics and therefore multiple modules.
 

Just to give one example, one of the modules would certainly have been about signs. This is an approximately 15-20 entity type section of the model which says that things can be represented by signs (names, descriptions, definitions, …) and that there are useful classifications of these from utterances of names, to names to file formats etc.


Signs, names, ... seems like a valuable semantic concept/"module".  15-20 entity types seems like a large number, however.  Given what I remember from neurological studies, visual recall is limited to 12-15 items and aural recall to 4.  I would advocate smaller modules/groupings that in turn may reference other modules.  The key to making this work, however, is tooling.  (Something we don't have.) 
 

Now what do you have that you don’t want to give names and descriptions of? So even though this makes a neat module, there is not much point in having it separate from the rest of the data model, since you are always going to need it.


But, other groups will need this "sign" concept as well, but for very different applications.  And, they will want to combine the semantics and use the constructs in their complete/integrated data model.  But, when the entities are in one, large, contiguous definition, it is difficult or impossible to pull the semantics apart.
 

The same is true of about half the entity types in the Part 2 data model (and nothing stops you ignoring the ones you don’t need anyway).


This comes down to the issue being discussed in the other thread for Track A, about finding content for reuse.  I did find valuable content for reuse in ISO 15926.  It was just difficult to find.
 

On the other hand, when we were developing Shell’s downstream (oil tanker to gas station) data model, we certainly did divide the data model (some 1700 entity types) into what we called subject areas (some 20+ of them). The core (essentially a subset of ISO 15926-2) was included in all the other models, and there were some other mid-level subject areas like person and organization, and location, that were also widely used (and a good thing too) and specifically developed to support that reuse


I would view your subject areas as domain models built from modules.  I tend to think that concepts like Person, Organization, Location, etc. are reusable modules.  FIBO certainly has them.  :-) I would have loved to have seen a basic Person ontology/model/pattern/archetype documented by ISO 15926 (since it came first in time), and then discussed and/extended by the FIBO team, instead of having an ISO 15926 person and a FIBO person.
 

, but the subject areas that looked at supporting specific parts of the business tended not to be imported by other subject areas, so there was something of a hierarchy of these subject areas, with subject areas mostly being imported from above in the hierarchy.

We limited the subject areas to around 200 entity types, with many much smaller. The reason for this limit is that it seems to be about what one person can hold in their mind without getting lost.


My experience is that the number is much smaller than 200, unless you clump the abstractions or have tooling to help manage the concepts, hierarchy and relationships.
 

So how does that compare with what you are looking to achieve?

 

Regards

 

Matthew West                           

Information  Junction

Mobile: +44 750 3385279

Skype: dr.matthew.west

matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx

http://www.informationjunction.co.uk/

https://www.matthew-west.org.uk/

This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.

Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire, SG6 2SU.

 

 




_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/



_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014  
Community Portal: http://ontolog.cim3.net/wiki/     (01)
<Prev in Thread] Current Thread [Next in Thread>