Moving to a New Blog and a New Focus

Starting today, I have a new blog focused on my research. It can be found at Hearing All Voices. 

This new work is based on the hypothesis that individuals' life stories provide detailed information and insight into a wide variety of personal and environmental issues. Peoples' stories can be mined to extract deeper understandings of these complex issues, as well as how people do (or do not) cope. 

Narratives are a way for humankind to structure and explain their experiences - defining external influences, internal motivations, decisions, dependencies, causes and effects, and much more. 

Infrastructure/tooling, ontologies and a simple graphical interface are being developed. The overall application ("Deep Narrative Analysis", DNA (tm)) utilizes, combines and adapts existing semantic, linguistic and machine-learning technologies. A wealth of background and linked data from the Internet can also be added. The goal is to allow complex analyses of narratives from many perspectives and utilizing many technologies and approaches.

For more details, please go to the blog page or to the OntoInsights web site.

Andrea

Using Ontology Design Patterns as Templates for Alignment

The paper, When owl:sameAs isn't the Same, has an interesting observation that I (often) have to address when working with my customers ...

Contrary to popular belief in some circles, formal semantics are not a silver bullet. Just because a construct in a knowledge representation language is prescribed a behavior using formal semantics does not necessarily mean that people will follow those semantics when actually using that language “in the wild.” This can be laid down to a wide variety of reasons. In particular, the language may not provide the facilities needed by people as they actually try to encode knowledge, so they may use a construct that seems close enough to their desired one. A combination of not reading specifications - especially formal semantics, which even most software developers and engineers lack training in - and the labeling of constructs with “English-like” mnemonics naturally will lead to the use of a knowledge representation language by actual users that varies from what its designers intended.

A variant of this subject also came up in the opening keynote address (From Artwork to Cyber Attacks) at the US. Semantics Symposium 2018 held last week at Wright State University. Craig Knoblock (USC Information Sciences Institute) gave the keynote and said that the mapping of information in the American Art Collaborative Project (slides 32-38) was difficult due to the various interpretations that different students applied to the backing ontology. Although the students who mapped the data all used the CIDOC CRM cultural heritage ontology, at the end of the day, there was much clean-up and coordination required. On slide 35, the statistics are reviewed - although only 76 files were mapped, there were 4636 commits required to get consistency!

So, clearly there is a problem. To solve it, I have started applying Ontology Design Patterns (ODPs) to define a consistent interpretation and usage of one or more ontologies for an application. I have found that ODPs are not just for ontology development and reuse!

The list below shows the information that I include in an ODP to inform people/teams that are using ontologies to define consistent semantics for their data:

• Description of why the pattern is needed and what problems are being solved - This includes:
  • A short statement describing what the pattern is used for and/or what is being mapped
  • The considerations that influenced the pattern or required the pattern to be created - for example:
    • When defining whole-part relationships, how deeply should the mereology hierarchy go?
    • What is needed to identify "the same" individuals?
    • How to determine the most appropriate type(s) for an individual?
    • What meta-data is needed?
• Design sources for the ODP (this is not be needed if the source is a single ontology)
• High level (block) diagram of the main concepts and relationships in the ODP
• Overview of each of the concepts/classes and relationships shown in the block diagram, as well as important sub-classes and sub-properties
• Include in the overview or in another section of the ODP any differences in approaches - for example, why a detailed class hierarchy might be used in one place but not in another
• Class and property diagrams related to the overview-ed classes and properties (such as can be generated by OntoGraph)
• Information on using the ODP
  • One or more examples illustrating the use of the ODP, along with instance/individual diagrams
  • A list of competency questions with SPARQL queries representing the questions
  • The results of applying the queries to the examples generated above (this step then also provides a set of test cases to gauge conformance)

I am pretty excited about how ODPs are working for my customers. Please let me know if you have similar problems and how/if you solved them.

P.S. If you aren't sure what competency questions are, please see the blog post, Breaking Down the "Documents and Policies" Project.

Andrea

Referencing Reused Classes and Properties When Working with Other Ontologies

While I am still toiling away on re-working OntoGraph to support diagramming RDF/RDFS (yes, it seems to be a major undertaking!), I thought that I would post a question that I received. Here it is ... "When reusing a bunch of different ontologies in a new ontology, how should reused classes and properties be referenced?" Should each of the reused ontologies be included "en masse", should individual entities be reused directly, should entities be redefined in the new ontology but using their original namespace, or should the entities be recreated? Unfortunately, this is a question that has no right answer, but I have some preferences.

First, let me explain the alternatives:

• Included "en masse" means using import statements for each re-used ontology, and then referencing the specific entities (classes and properties) that are actually needed. Everything is referenced in the namespace where it was defined, and nothing is redefined or recreated.
• Reusing a class or property directly means referencing that class or property but without importing the entire ontology. Everything is referenced using the namespace where it was defined, and nothing is redefined or recreated. But, you might end up with a triple that looks like this: myNamespace:someKindOfDate a owl:DatatypeProperty, owl:subPropertyOf dcterms:date. And, it is up to the infrastructure to resolve the "dcterms" (Dublin Core) namespace to get the details of the date property.
• Redefining entities means that you take the classes or properties that should be reused and include their definitions in your ontology. So, if you are using the Dublin Core "creator" concept, you would include a definition for dcterms:creator. You might even add more information, as new predicates/objects defined for the entity, or maybe just copy over the existing predicates. Why might you do this? One reason is to have all the necessary details in one place. But, just as this is considered bad practice in programming (having multiple copies of the same code), I believe that copy and paste of another ontology's definition (using the same IRI/URI) is also wrong. You could end up with duplicated (or worse) divergent, or out-of-date declarations.
• Recreating entities is similar to redefining them, but different in some important ways. In this case, you create a semantically equivalent entity. Using the example above, a myNamespace:author entity might be created and the relevant details defined for it. In addition, you define an equivalentClass/Property declaration, linking it to its source (in this case, dcterms:creator). Taking this approach, if dcterms:creator means something different in a future version, the equivalentProperty statement can be removed. Or, if a new metadata standard is dictated by your company or customer, you simply add another newMetadataNamespace:author equivalentProperty declaration.

Next, I will try to give all the pros and cons of using the same vs different namespaces, and recreating entities from one namespace in another.

A namespace exists to establish the provenance of the entities defined within it, and to identify that the entities are related. Ontologies should have loose coupling and tight cohesion, just like code - and the namespace can (should?) indicate the purpose/domain-space of the ontology. You can certainly group everything under the umbrella of a namespace that represents "my overall application space" - but that seems a bit too broad. Also, you might have another application in the future where you re-use one or more of your own ontologies - and then, one might question the "my overall application space" namespace, or question which entities in that namespace are relevant to the new application.

Also, a namespace helps to disambiguate entities that might have the same name - but not necessarily the same semantics (or detail of semantics) - across different ontologies. For example, a Location entity in an Event ontology (or more correctly, ontology design pattern, ODP) should not go into detail about Locations (that is not the purpose of the ontology). Defining locations would be better served by other ontologies that specifically deal with network, spatial-temporal, latitude-longitude-altitude and/or other kinds of locations. So, an under-defined Location in an Event ODP can then link - as an equivalent class - to the more detailed location declarations in other "Location"-specific ODPs. In this way, you get loose coupling and tight cohesion. You can pull out one network location ODP and replace it by a better one - without affecting the Event ODP. In this case, you would only change the equivalentClass definition. :-)

As for re-creating entities in the ODP namespace, that is really done for convenience. I can actually argue both sides of this issue (keeping the entities with their namespaces/provenance versus recreating them). But, erring on the side of simplicity, I recommend recreating entities in the new ontology's namespace (the last bullet above). This is especially relevant if only a portion of several existing ontologies/namespaces will be re-used. Why import large ontologies when you only need a handful of classes and properties? This can confuse your users and developers as to what is really relevant. Plus, you will have new entities/properties/axioms being defined in your new ontology. If you do not recreate entities, you end up with lots of different namespaces, and this translates to lots of different namespaces in your individuals. Your users and developers can become overwhelmed keeping track of which concept comes from which namespace.

For example, you may take document details from the SPAR DoCo ontology (http://www.sparontologies.net/ontologies/doco/source.ttl) and augment it with data from the Dublin Core (http://dublincore.org/2012/06/14/dcterms.rdf) and PRISM (http://prismstandard.org/namespaces/basic/2.0/) vocabularies, and then add details from the PROV-O ontology (http://www.w3.org/ns/prov-o). All these classes and properties use different namespaces and it gets hard to remember which is which. E.g., "foo" is an instance of the doco:document class and uses the dcterms:publisher and prism:doi properties, but is linked to a revision using a prov:wasDerivedFrom property. This could lead to errors in creating and querying the instances. It seems easier to say "foo" is an instance of the myData:document class, and uses the predicates myData:author, myData:publisher, myData:doi and myData:derivedFrom (where "myData" is the namespace of the ODP for tracking document details).

I know that some might disagree (or might agree!). If so, let me know.

Andrea

OntoGraph Server

In order to make everyone's life easier, we (Nine Points Solutions) are sponsoring a hosted server running the latest release of OntoGraph and Stardog.

Feel free to give it a try by uploading your ontology, and generating a graph.

Anything that is uploaded is used only in generating the graph and then all details are deleted.

Andrea

P.S. Maintenance will be done (if needed) on Saturdays, noon-4pm Eastern time.

Graphing with OWL Reasoning

Another version of OntoGraph (V1.0.2) was released today. The main goal was to add OWL reasoning to determine individuals' types. Why might this be important? Well, an individual might be referenced in an ontology, but not defined with a rdfs:type. Or, the individual might be defined with a type, and then also used as the subject or object in a triple. If the predicate of the triple (the relating property) is defined with domains and/or ranges, then a reasoner can infer the type(s) of the individual. This is also useful to find errors in the ontology, its logic and its semantics (more on that later).

Here is a simple example:

@prefix ninepts: <http://purl.org/ninepts/test#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://purl.org/ninepts/test> rdf:type owl:Ontology .

<http://purl.org/ninepts/test#class1> rdf:type owl:Class .

<http://purl.org/ninepts/test#class2> rdf:type owl:Class .

<http://purl.org/ninepts/test#class3> rdf:type owl:Class .

<http://purl.org/ninepts/test#class4> rdf:type owl:Class .

<http://purl.org/ninepts/test#objProp1> rdf:type owl:ObjectProperty ;
   rdfs:domain ninepts:class3, ninepts:class4.

<http://purl.org/ninepts/test#objProp2> rdf:type owl:ObjectProperty ;
   rdfs:range ninepts:class1, ninepts:class2 .

<http://purl.org/ninepts/test#individual1> ninepts:objProp1 ninepts:individual2.

<http://purl.org/ninepts/test#individual3> ninepts:objProp2 ninepts:individual4.

This example is written in using the Turtle syntax, and basically defines 4 classes (class1 - class4), 2 properties (objProp1 and objProp2), and 4 individuals (individual1 - individual4). The property, objProp1, is defined with 2 classes as its domain (and no range), while objProp2 is defined with 2 classes as its range (and no domain). (No domain or no range for an object property means that there is no intended semantic - that anything, any "owl:Thing", is the domain or range.) The individuals are defined in 2 triples indicating that individual1 is related to individual2 (via objProp1), and individual3 is related to individual4 (via objProp2).

Without OWL reasoning, the individuals have no types. In fact, OntoGraph does not even find any individuals since it "locates" individuals by querying for any entity that has an explicit type of owl:NamedIndividual, or that has a type that begins with a prefix other than OWL or RDF/RDFS. (The query allows us to avoid returning classes (type owl:Class) and properties (type owl:ObjectProperty or owl:DatatypeProperty) when searching for individuals and their types.)

But, if we run OntoGraph with reasoning turned on, then we find that there are indeed 4 individuals, and that individual1 has the types defined for the domain of objProp1, and individual2 has the types defined for the range of objProp2. This is shown in the figure below, which was generated by OntoGraph.

If this seems odd, think about how the reasoner works ... The ontology defined individual1 as the subject of a triple with the predicate, objProp1. We know that any subject (the domain of the property) of objProp1 is defined to be of types, class3 and class4. So, individual1 is "reasoned" to be of those 2 types. Similarly, individual4 is the object of a triple with the predicate, objProp2. And, we know from the ontology that any object (the range of the property) of objProp2 is defined to be of types, class1 and class2. There you have it ...

The reasoner can't determine anything about individual2 or individual3, except that they are themselves individuals. The reasoner figures this out since they are an object and subject (respectively) in triples whose predicates are object properties. By the way, the reasoner also determined that they are of type, owl:Thing, which doesn't tell you much (everything is of type, owl:Thing, unless there is a logical inconsistency in the ontology). OntoGraph does not bother to show that detail since it adds no information to the graph (but does clutter it up).

Now, why did I talk earlier, about illustrating errors in the ontology? If you look at the ontology definition above, you see that the domain of objProp1 is "ninepts:class3, ninepts:class4". Many people writing ontologies mistakenly think that the definition means that the domain is EITHER class3 OR class4. But, that is incorrect. The definition actually means that the domain is BOTH class3 AND class4. Therefore, an individual must be of BOTH types (multiple inheritance), or stated another way, is defined as the intersection of both types. There are some ways to get around this, as discussed in these two posts from StackOverflow (using one property with multiple domains and how to define multiple domains and ranges). I am not going to repeat the answers (which are both very good), but will talk more about reasoning and errors in my next post.

As always, let me know if you have any questions.

Andrea

OntoGraph V1.0.1 and a Discussion of VOWL

Continuing the evolution of OntoGraph, we published fixes to three minor issues, and updated the README text to address user questions that we received. The README, code, and jar and zip (in the /ontograph-<major.minor.release#> directory) are all updated. The changes are all described in the commit history. In addition, a few new issues were added to our backlog based on feedback and questions. Take a look at the current set of issues and let me know if you have issues to add or want to highlight which ones are important to you. Or, you can just add a comment to the issues directly.

Right now, we are planning on another update (V1.1.0) at the end of October. We will be addressing all the known bugs and adding support for diagramming straight RDF - i.e., to support Linked Data.

Enough of that ... Let's move onto discussing the graph output for a VOWL visualization from OntoGraph versus what is defined in the official specification. First off, per the specification ...

OWL elements such as owl:allValuesFrom, owl:someValuesFrom, owl:hasValue, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, and owl:DataRange (rdfs:datatype in OWL 2 which has a representation in the current specification) are not part of the VOWL visualization but could be displayed in another way (e.g. as text information in a tooltip or sidebar). This is also the case for the OWL elements owl:Ontology, owl:differentFrom, owl:AllDifferent, owl:distinctMembers, owl:Restriction, owl:onProperty, owl:AnnotationProperty, and owl:OntologyProperty that serve as containers of other elements, link individuals, or define ontology metadata.

OntoGraph diverges from the specification for annotation properties. These are displayed in a graph, similar to datatype properties. Ignoring these properties can omit valid information (usable constructs) from a graph. For example, the Friend-Of-A-Friend ontology (FOAF) defines annotation properties for information mapped from the Web of Trust (WOT) and Dublin Core schemas. These properties (especially ones from Dublin Core such as "description") are often used on class, property and element declarataions.

For many of the restriction-related elements listed above (such as owl:Restriction, owl:all/someValuesFrom, ...), OntoGraph outputs labeled edges and text in "UML boxes" that define the details. In my experience, when restrictions are used, understanding them is essential to understanding the ontology.

As regards OWL connectives, VOWL easily shows equivalencies, unions, intersections, complements or disjoint definitions between named classes. But, the defined graphing approach fails when one or more of the related classes are blank (anonymous/un-named) nodes. Consider how equivalent classes are shown - as a circle "with a double border... One of the class labels is the main label, while the rest is listed in square brackets (abbreviated if they do not all fit)." Next, consider how connectives (unions, intersections, etc.) are shown - as two or more classes connected via dashed lines (without arrowheads), to an image of a Venn diagram labeled with a union, intersection or complement logical symbol. The Venn diagram image "represents the anonymous class of the owl:unionOf [owl:intersectionOf, ...] statement".

There are two problems with these conventions when dealing with nested blank nodes. For example, consider a class, foo, that is equivalent to the union of two other blank nodes - the complement of a class, bar, and an intersection of the classes, classA and classB. Since the union node (the equivalency) is anonymous/un-named, there is nothing to display on the second line of foo's node label. As for the second problem, although the union, intersection and complement images can be diagrammed and connected to the relevant classes via dashed lines ... there is no way to understand that the complement and intersection definitions are the entities being unioned, unless arrowheads are used. (Without arrowheads, there could be many interpretations - such as, classB is the intersection of classA and a union declaration.) In standard VOWL, there are simply dashed lines running between all the images. This is shown in the image below.

This same ontology is shown as output by OntoGraph:

OntoGraph addresses VOWL's connectives issues by drawing equivalencies similar to "Subclass of" declarations, and by using arrowheads to indicate exactly what is unioned, intersected or complemented. As another example, here is a snippet of a graph of the W3C Turtle Primer, a complex ontology based on union, intersection, complement and disjoint declarations, as well as restrictions. The majority of this detail would be missing in an "official" VOWL diagram.

Another thing that is missing in the VOWL specification is the display of individuals. Whereas many ontologies do indeed focus on the TBox (the concepts and relationships of a domain), the Linked Data and application worlds have to deal with individuals/instances (the ABox). Being able to diagram your instances is important. But, even if you want to restrict yourself to the TBox world, when you have "one-of" definitions (for enumerations and restrictions), graphing these is important. OntoGraph accepts that Abox individuals are not graphed in VOWL, but does support individual diagrams in the custom, Graffoo and UML visualizations. In addition, OntoGraph displays "one-of" declarations using a UML Note format. An example can be seen at the bottom of the image above.

There are two more major (but related) issues to discuss regarding VOWL ... The first issue involves how node and property names are displayed in a graph. VOWL recommends that an implementation display any rdfs:label that may be defined for a class or property. But, "if elements do not have an rdfs:label, it is recommended to take the last part of the URI as label, i.e. the part that follows the last slash (/) or hash (#) character. Labels may be abbreviated if they do not fit in the available space (e.g. "Winnie-the-Pooh" → "Winnie…"). The full label should be shown on demand in these cases (e.g. in a tooltip or sidebar)." Unfortunately, this last aspect is not possible to support in yEd or any static copy of a graph. And, even the Example in the VOWL Specification does not show the full label when an abbreviated name is displayed!

The second, related issue is that because either a label or local name is displayed, VOWL does not include prefixes/full URIs in its graph. Instead, colors are used to distinguish what is "external" to an ontology (i.e., when a declared element uses a different base URI than the ontology URI/IRI). "External" classes and properties are shown in a darker color (darker blue for OWL classes and properties). In addition, the class nodes also carry the word, "external", in brackets, on the second line. There are several problems with this approach:

• It will not be possible to distinguish the source of "external" references, and the problem is compounded if there are multiple imported/referenced vocabularies or ontologies. For example, the FOAF diagram includes a node (Spatial Thing) from the WGS84 Geo Positioning RDF vocabulary (WGS84) and another node (Concept) from the SKOS vocabulary (skos). Both of these are displayed in dark blue in the VOWL graph, with the text, "[external]", under their labels. OntoGraph follows this convention.
• If there are equivalencies to multiple class declarations (from different, external ontologies) but those declarations have the same local name, then the local name will be repeated. For example, FOAF defines equivalent classes for the FOAF Person concept - linking it to the Schema.org Person class and the Person class from Tim Berner-Lee's Contact ontology. The result is a node whose label is "Person [Person, Pe...]". For domain experts reviewing a graph, this would be confusing at best. As above, OntoGraph follows this convention.

That's it for VOWL! Let me know if this information is helpful. Thanks for reading!

Andrea

What can be learned from the OntoGraph project?

OntoGraph was introduced in my last post, OWL Ontology Graphing Program Available as Open Source. And there are a lot of interesting things in the code! Over the next weeks, I want to take time to relay my learnings, as well as to provide insights into OWL ontologies, SPARQL queries, Bootstrap, Backbone and RESTful interfaces, the Model-View-Controller and other patterns, Spring Boot, Lombok, programming Stardog, testing, Gradle builds, and much more. Some of this will be basic stuff (but hopefully useful to some of my readers) and some will be more advanced. Feel free to pick and choose, or let me know what you want to hear about!

But, first, I want to talk about our development environment ...

The precursor to OntoGraph was originally created in about 2 days to provide some basic diagrams of a customer's ontology. Hand-drawing all the classes, properties, axioms, etc. of the ontologies was too painful and error-prone. Using a tool like OntoViz with Protege was just not flexible enough, and the images were not what the customer wanted to see. The ProtegeVOWL plug-in was also not sufficient since VOWL does not diagram all the necessary constructs (I will talk more about this in a future post). In addition, the customer did not want to be tied to using Protege since they weren't ontologists. They just wanted a diagram and to be able to play around with the layout.

Well, the 2 day "quick and dirty" version worked and the customer had their diagrams. That could have been the end of the story. But, we hired an intern who needed to learn about ontologies, the Stardog triple store, SPARQL queries and lots of other things. So, we decided to use the graphing program as a learning experience. We took the initial work and decided first to just address some bugs. Then, we decided to add the ability to customize the output, which required a front-end. Then, we added support for different kinds of visualization (Graffoo, VOWL, UML). And, the program grew. We changed directions, rewrote whole sections of the program, updated our approach to the front-end at least three times, updated our approach to testing at least twice, and upgraded our infrastructure at least twice (updating the Gradle, Stardog, Javascript libraries, etc.). We put months of work into the program, definitely taking an agile approach and learning to "fail fast".

There are lessons here ... Good software takes time. There is always more to learn. Don't be afraid to take what you learn and rewrite what is problematic (as long as you have time and there are no other programming fires burning). There is always something that you can do better. And, always remember that Stack Overflow is your friend!

Well, ok then ... back to agile. For our agile environment, we used Atlassian's products - JIRA for issue tracking and managing our process (Kanban actually), integrated with a Bitbucket Git repository for version control, and Bamboo as our continuous integration environment. Since we are a small company, this was an easy and cheap solution ($10 for each product). In addition, when we decided to get serious about releasing the code as open-source, we also decided to incoporate SonarQube into our continuous integration environment.

As someone who either spent too much or too little time on code reviews, SonarQube was great! Per Wikipedia, it provides "continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells and security vulnerabilities" (http://en.wikipedia.org/wiki/SonarQube). And, it does this for 20+ programming languages (but we only needed Java, JavaScript and CSS). This took a lot of the pain out of code reviews. I focused on whether the method and property names were understandable, if the code seemed reasonable and was somewhat efficient, and things like that. SonarQube took care of finding problems related to bad practice, lack of efficiency, and errors (such as not initializing a variable). In addition, SonarQube would complain if you nested if/while/for/switch/try statements too deeply, or implemented methods with too many parameters or that were too complex. In reality, SonarQube was tougher on my code than any team review that I had experienced in the past.

Now, you can make things easier on yourself and change the defaults in the SonarQube rules. For example, you can allow a complexity of 30 instead of 15, or allow nesting of if/while/... past 3 levels. But, we didn't do that for OntoGraph. We figured that we would keep the defaults and fix most of the problems (or, we would eventually fix them). There are some "issues" that are just false positives, and others that we have not yet addressed. If you want to find them in the OntoGraph code, just look for "//NOSONAR" and then the explanation that follows. The "//NOSONAR" comment tells SonarQube to ignore the issue for now - either it is a false positive or we acknowledge that there is a problem and are willing to accept the issue for now. I think that this is a valuable approach. Most of the existing issues in OntoGraph are complexity, and we will fix those!

Another important aspect is test coverage. When we decided to release OntoGraph as open source, we set a testing threshold of at least 80% on the back-end processing classes (so this would be GraphController.java, GraphDAO.java and all the classes in the graphmloutputs folder). All of these classes have coverage between 93.2% and 98.3%, except one. TitleAndPrefixCreation.java has a test coverage of 77.8%, with 2 (yes, 2) uncovered lines. Those lines throw an IllegalAccessError exception if something tries to instantiate the class (which should not be done since the class contains only 1 static method). Oh well, we decided that this was definitely good enough!

You can see SonarQube in action by downloading OntoGraph and following SonarQube's instructions for Getting Started in Two Minutes. After starting and logging into SonarQube according to the instructions, go to where you downloaded OntoGraph. Type "./gradlew sonar" or "gradlew.bat sonar" for Windows (making sure that you have installed Gradle :-). After that completes, you can see all the rules/issues, statistics and more.

P.S. Sorry for the riff on SonarQube, but I wanted to hit on some cool details. And, I will talk about how Gradle supports SonarQube in a future post. This post just got way too long!

Andrea

OWL Ontology Graphing Program Available as Open Source

It has been forever since I last blogged on this site (more than a year, for which I feel terrible). I have been wrapped up in work for a customer whose details are proprietary, and I was also slowly working to create (what I hope will be valuable) ontology graphing software. I wished that the work on the graphing software would have been available sooner, but better late than never ... The graphing software is called OntoGraph, is finally at a point where it is acceptable to publish, and I can freely discuss it on the blog! So, here we go ...

You can check out the work at Nine Points Solutions' GitHub repository.

OntoGraph is a Spring Boot application for graphing OWL ontologies (yes, the title says this). It lets you go from XML/RDF, Turtle and several other OWL syntaxes to a custom, Graffoo, VOWL or UML-like diagram. For example, you can go from something like this (this excerpt comes from the Friend of a Friend, FOAF.rdf ontology - you can see the complete FOAF ontology at http://xmlns.com/foaf/spec/index.rdf) ...



To ...



The above image is a VOWL rendering of FOAF.

OntoGraph is designed with a Bootstrap- and Backbone-based GUI (written in Javascript), interfacing with a RESTful API. The main program is written in Java. It operates by creating various GraphML outputs of a user-provided OWL ontology file. (Or, it also accepts a zip file of a set of ontology files). The program stores the ontologies in the Stardog triple store, then runs a series of queries to return the necessary information on the classes, properties, individuals... to be diagrammed. Layout of the resulting GraphML is handled by another program. (We recommend yEd.)

Four visualizations of ontology data can be generated:

• Custom format (defined to fit existing business or personal preferences)
• Graffoo
• UML-like
• VOWL

And, information can be segmented to display:

• Class-related information (subclassing, equivalent and disjoint classes, class restrictions, ...)
• Individual instances, their types, and their datatype and object property information
• Property information (datatype and object properties, functional/symmetric/... properties, domain and range definitions, ...)
• Both class and property information

Complete information about OntoGraph, how to run it, and issues and upcoming features are available at the GitHub repository. Also, there is a pre-publication version of a paper there, there explains OntoGraph and why it was created. (The paper will be available in the next issue of the Journal of Applied Ontology, from IOS Press.)

So, now that OntoGraph is finally published, I can start to blog about its components, design and design decisions, testing, and lots of other details. I just needed something concrete!

I hope that you find the program useful!

Andrea

Ontologies for Reuse Versus Integration

There is ongoing email discussion in preparation for this year's Ontology Summit on "semantic integration". I thought that I would share one of my recent posts to that discussion here, on my blog. The issue is reuse versus integration ...

For me, designing for general reuse is a valid goal and valuable (if you have the time, which is not always true). (Also it was the subject of the Summit 2 yrs ago and many of my posts from that time - March-May 2014!) But reusing an ontology or design pattern in multiple places is not semantic integration. Reuse and integration are different beasts, although they are complimentary.

I have designed ontologies for both uses (reuse and integration), but my approach to the two is different. Designing for reuse is usually focused on a small domain that is well understood. There are general problem areas (such as creating ontologies/design patterns for events, or to support Allen's time interval algebra) that are generally applicable. In these areas, general design and reuse makes sense.

Over the years, however, I have been much more focused on designing for integration (especially in the commercial space). In my experience, companies are always trying to combine different systems together - whether these systems are legacy vs new, systems that come into the mix due to acquisition, internal (company-centric) vs external (customer-driven), dictated by the problem space (combining systems from different vendors or different parts of an organization to solve a business problem), ...

It is ok to try to be forward-thinking in designing these integration ontologies ... anticipating areas of integration. But, I have been wrong in my guesses (of what was needed in the "future" ontology) probably more than I have been right - unless it was indeed in general problem domains.

So, my integration "rules of thumb" are:

• Get the SMEs in a particular domain to define the problem space and their solution (don't ever ask the SMEs about integrating their domains)
• Don't ever give favor to one domain over another in influencing the ontology (you are sure to not be future-proof)
• Focus on the biggest problem areas first, and find the commonalities/general concepts (superclasses)
• Place the domain details "under" these superclasses
• Never try to change the vocabulary of a domain, just map to/from the domains to the "integration" ontology
• Never map everything in a domain, just what needs to be integrated
• Look for smaller areas of "general patterns" that can be broadly reused
• Have new work start from the integrating ontology instead of creating a totally new model
• Update the integrating ontology based on mapping problems and new work (never claim that the ontology is immutable)
• Utilize OWL's equivalentClass/disjointFrom/intersectionOf/unionOf/... (for classes), sameAs/differentFrom (for individuals) and class and property restrictions to tie concepts together in the "mapped" space
• Be focused on concept diagrams and descriptions, documenting mapping details, ... and not that you are using an ontology
• Clearly document ontology/concept, relationship, ... evolution

Let me know if this resonates with you or if you have different "rules of thumb".

Andrea

2016 and continuing posts on ontologies

Well, 2015 seems to have gotten away from me. Over the last year, I have been working to design and implement several ontologies for policy-based management. The work is based on Complexible's Stardog graph database, with services accessed through a RESTful API, and with a front-end, single-page web application created with Bootstrap and Backbone. It has been a blast working with and learning all these technologies, and my new year's resolution is to get back into writing my blog and share some of my learnings.

Another thing that I am doing is related to the International Association for Ontology and Its Applications (IAOA). More specifically, I am a part of the Semantic Web Applied Ontologies Special Interest Group (SWAO SIG). The SIG is continuing the work of the 2014 Ontology Summit and facilitating discussions of ontologies and their development and application. I will be contributing to those discussions in 2016, and started with a short post on the various definitions of the term, ontology. Check out the SWAO link above for the discussion!

That's it for now. Happy 2016!

Andrea

More links to document-related ontologies

Over the course of the last few weeks, a few people have emailed me additional references for document ontologies. These are both valuable links. I want to use them (in my solution) and so, need to expand the references from my previous post to add these:

• SALT (Semantically Annotated LaTeX for Scientific Publications) Document Ontology
• SALT is described in this paper, but unfortunately none of the associated/referenced ontologies are still available
• FRBRoo
• A harmonization of the FRBR model (an entity-relationship model from the International Federation of Library Associations and Institutions, published in 1998) and the CIDOC CRM4 model (ISO Standard 21127.5 developed by ICOM-CIDOC, the International Council for Museums – International Committee on Documentation)
• Per the documentation for Version 2 of the model, FRBRoo is "a formal ontology that captures and represents the underlying semantics of bibliographic information and therefore facilitates the integration, mediation, and interchange of bibliographic and museum information"
• Also, there is an "owlified" version available at https://github.com/erlangen-crm

Given these new insights, I have a bit more work to do on my solution.

Andrea

Document-related ontologies

In my previous post, I defined the competency questions and initial focus for an ontology development effort. The goal of that effort is to answer the question, "What access and handling policies are in effect for a document?"

A relatively (and judging by the length of this post, I do mean "relatively"!) easy place to start is by creating the document-related ontology(ies). (Remember that I am explicitly walking through all the steps in my development process and not just throwing out an answer. At this time, I don't know what the complete answer is!)

Unless your background is content management, or you are a metadata expert, the first step is to learn the basic principles and concepts of the domain being modeled. This helps to define the ontologies and also establishes a base set of knowledge so that you can talk with your customer and their subject-matter experts (SMEs). Never assume that you are the first person to model a domain, or that you inherently know the concepts because they are "obvious". (Unless you invented the domain, you are not the first person to model it. Unless you work in the domain, you don't really know it!)

Beyond just learning about the domain, there are additional advantages for understanding the basic principles and concepts, and looking at previous work ... First, you don't want to waste the experts' time. That is valuable and often limited. The more that you waste an expert's time, the less that they want to talk to you. Second, you need to understand the basics since these are sometimes so obvious to the experts that they consider it "implicit". I.E., they don't say anything about the basics and their assumptions, and eventually you get confused or lost (because you don't have the necessary background or make your own assumptions in real-time, in the conversations). Third, it is valuable to know where mistakes might have been made or where models were created that seem "wrong" to you. Also, it is valuable to know where there are differences of opinion in a domain - and know where your experts land, on which side of a debate. Understanding boundary cases, and maybe accounting for multiple solutions, may make the difference between your ontology succeeding or failing.

Background knowledge can come from many places. But, I usually start with Google, Bing, Yahoo, etc. (given your personal preference). I type in various phrases and then follow the links. Here are some of the phrases that I started with, for the "documents" space:

• Dublin Core (since that was specifically mentioned in the competency questions)
• Document metadata
• Document management system
• Document ontology (since there may be a complete ontology ready to adapt or directly reuse)

Clearly this is just a starting list, since each link leads to others. It is valuable to review any Wikipedia links that come up (as they usually provide a level-set). Especially, pay attention to standards. Then dig a bit deeper, looking at academic and business articles, papers and whitepapers. You can do this with a search engine and by checking your company's, or an organization's (such as IEEE and ACM), digital library.

Here is where my initial investigations took me:

• Dublin Core Metadata Initiative Specifications (including the RDF encoding)
• Wikipedia entry on document management systems (a short overview and level-set)
• Sharepoint document access and management and related (See also) links (valuable since lots of businesses use Sharepoint, and this article also provides insight into planning a document management system)
• OASIS Open Document Format (ODF) Specification
• SPAR's (Semantic Publishing and Referencing) Document Components Ontology
• Muninn Documents Ontology Specification

You can also take a look at the metadata-ontology that I developed from Dublin Core and SKOS, and discussed in earlier posts.

As for the RDF and ontologies, I don't want to take them "as-is" and just put them together. I first want to quickly review them, as well as the ideas from relevant other references (such as OASIS's ODF). Then, we can begin to define a base ontology. It is important to always keep our immediate goals in focus (which are mostly related to document metadata), but also have an idea of probable (or possible) extensions to the ontologies.

When creating my ontologies, I usually (always?) end up taking piece-parts and reusing concepts from multiple sources. The parts can be imported and rationalized via an integrating ontology, or are cut and pasted from the different sources into a new ontology. There are advantages and disadvantages to each approach.

When importing the original ontologies and integrating them (especially when using a tool like Protege), you end up with a large number of classes and properties, with (hopefully) many duplicates or (worst case) many subtle differences in semantics. This can be difficult to manage and sort through, and it takes time to get a good understanding of the individual model/ontology semantics. Another problem with this approach is that the ontologies sometimes evolve. If this happens, URLs may change and your imports could break. Or, you may end up referencing a concept that was renamed or no longer exists. Ideally, when an ontology is published, a link is maintained to the individual versions, but this does not always happen. I usually take the latest version of an ontology or model, and save it to a local directory, maintaining the link to the source and also noting the version (for provenance).

Cutting and pasting the various piece parts of different ontologies makes it easier to initially create and control your ontology. The downside is that you sometimes lose the origins and provenance of the piece parts, and/or lose the ability to expand into new areas of the original ontologies. The latter may happen because those ontologies are not "in front" of you ("out of sight, out of mind") or because you have deviated too far from the original semantics and structure.

In my next posts, I will continue to discuss a design for the document-related ontologies (focusing on the immediate needs to reflect the Dublin Core metadata and the existence/location of the documents). In the meantime, let me know if I missed any valuable references, or if you have other ideas for the ontologies.

Andrea

Breaking Down the "Documents and Policies" Project - Competency Questions

Our previous post defined a project for which a set of ontologies is needed ... "What access and handling policies are in effect for a document?" So, let's just jump into it!

The first step is always to understand the full scope of work and yet to be able to focus your development activities. Define what is needed both initially (to establish your work and ontologies) and ultimately (at the end of the project). Determine how to develop the ontologies, in increments, to reach the "ultimate" solution. Each increment should improve or expand your design, taking care to never go too far in one step (one development cycle). This is really an agile approach and translates to developing, testing, iterating until things are correct, and then expanding. Assume that your initial solutions will need to be improved and reworked as your development activities progress. Don't be afraid to find and correct design errors. But ... Your development should always be driven by detailed use cases and (corresponding) competency questions.

Competency questions were discussed in an earlier post, "General, Reusable Metadata Ontology - V0.2". (They are the questions that your ontology should be able to answer.) Let's assume that you and your customer define the following top-level questions:

• What documents are in my repositories?
• What documents are protected or affected by policies?
• What documents are not protected or affected by policies? (I.E., what are the holes?)
• What policies are defined?
• What are the types of those policies (e.g., access or handling/digital rights)?
• What the details of a specific policy?
• Who was the author of a specific policy?
• List all documents that are protected by multiple access control policies. And, list the policies by document.
• List all documents that are affected by multiple handling/digital rights policies. And, list the policies by document.

These questions should lead you to ask other questions, trying to determine the boundaries of the complete problem. Remember that it is unlikely that the customers' needs will be addressed in a single set of development activities. (And, work will hopefully expand with your successes!) Often, a customer has deeper (or maybe) different questions that they have not yet begun to define. Asking questions and working with your customer can begin to tease this apart. Even if the customer does not want to go further at this time, it is valuable to understand where and how the ontologies may need to be expanded. Always take care to leave room to expand your ontologies to address new use cases and semantics.

This brings us back to "General Systems Thinking". It is important to understand a system, its parts and its boundaries.

Here are some follow-on questions (and their answers) that the competency questions could generate:

• Q: Given that you have document repositories, how are the documents identified and tagged?
• A: A subset of the Dublin Core information is collected for each document: Author, modified-by, title, creation date, date last modified, keywords, proprietary/non-proprietary flag, and description.
• Q: How are the documents related to policies?
• A: Policies apply to documents based on a combination of their metadata.
• Q: Will we ever care about parts of documents, or do we only care about the documents as a whole?
• A: We may ultimately want to apply policies to parts of documents, or subset a document based on its contents and provide access to its parts. But, this is a future enhancement.
• Q: Do policies change over time (for example, becoming obsolete)?
• A: Yes, we will have to worry about policy evolution and track that.
• Q: What policy repositories do you have?
• A: Policies are defined in code and in some specific content management systems. The goal is to collect the details related to all the documents and all the policies in order to guarantee consistency and remove/reduce conflicts.
• Q: Given the last 2 competency questions, and your goal of removing/reducing conflicts, would you ultimately like the system to find inconsistencies and conflicts? How about making recommendations to correct these?
• A: Yes! (We will need to dig into this further at a later time in order to define conflicts and remediation schemes.)

Well, we now know more about the ontologies that we will be creating. Initially, we are concerned with document identification/location/metadata and related access and digital rights policies. We can then move onto the provenance and evolution of documents and policies, and understanding conflicts and their remediation.

So, the next step is to flesh out the details for documents and policies. We will begin to do that in the next post.

Andrea

Understanding semantics and Pinker's "Curse of Knowledge"

I recently read an interesting editorial in the Wall Street Journal from Steven Pinker. It was titled, "The Source of Bad Writing", and discussed something that Pinker called the "Curse of Knowledge".

Curse of Knowledge: a difficulty in imagining what it is like for someone else not to know something that you know

After reading that article, looking at the various posts asking where to find good online courses on semantic technologies and linked data, discussing problems related to finding qualified job candidates, and listening to people (like my husband) who say that I make their heads explode, I decided to talk about semantics differently. Instead of explaining specific aspects of ontologies or semantics, or writing about disconnected aspects of the technologies, I want to go back to basics and explore how and what I do in creating ontologies, what to worry about, how to create, evolve and use an ontology and triple store, ...

Then, I need some feedback from my readers. As Steven Pinker says,

A ... way to exorcise the curse of knowledge is to close the loop, ... and get a feedback signal from the world of readers—that is, show a draft to some people who are similar to your intended audience and find out whether they can follow it. ... The other way to escape the curse of knowledge is to show a draft to yourself, ideally after enough time has passed that the text is no longer familiar. If you are like me you will find yourself thinking, "What did I mean by that?" or "How does this follow?" or, all too often, "Who wrote this crap?"

There are many good papers, books and blog posts on the languages, technologies and standards behind the Semantic Web. (Hopefully, some of my work is there.) I don't want to create yet another tutorial on these, but I do want to talk about creating and using ontologies. So, for the next 6 months or so, my goal is to design and create a set of ontologies through these blog posts - delving into existing ontologies, and semantic languages/standards and tools. In addition, as the ontologies are created, I will discuss using them - which moves us into triple stores and queries.

As we go along, I will reference specs from the W3C, other blog posts and information and tools on the web. My goal is that you can get all of the related specs, tools and details for free. I hope that you will be interested enough to scan or download them (or you might know and use them already), and ask more questions. What is important is to understand the basics, and then we can build from there.

The first question is "What is the subject of the ontology that we will be building and using?" Since I am interested in policy-based management, I would like to develop an ontology and infrastructure to answer the question: "What access and handling policies are in effect for a document?"

At first blush, you might think that the process is relatively easy. Find the document, get its details, find what policies apply, and then follow those policies. But, the policies that apply are possibly dictated by the subject or author of the document, or when it was written (since regulations and company policies change over time). Worse, the access policies are likely defined (and stored) separately from the handling/digital rights policies, but need to be considered together. Lastly, how do we even begin to understand what the policies are saying?

I hope that you see that I did not choose an easy subject at all, but one that will take some time to think through and develop. I am looking forward to doing this and would like your feedback, questions, comments and advice, along the way.

Andrea

Another OWL diagramming transform and some more thoughts on writing

With summer in full-tilt and lots going on, I seem to have lost track of time and been delinquent in publishing new posts. I want to get back into writing slowly ... with a small post that builds on two of my previous ones.

First, I wrote a new XSL transform that outputs all NamedIndividuals specified in an ontology file. The purpose was to help with diagramming enumerations. (I made a simplifying assumption that you added individuals into a .owl file in order to create enumerated or exemplary individuals.) The location of the transform is GitHub (check out http://purl.org/NinePts/graphing). And, details on how to use the transform (for example, with the graphical editor, yED) is described in my post, Diagramming an RDF/XML ontology.

If you don't want some individuals included, feel free to refine the transform, or just delete individuals after an initial layout with yEd.

Second, here are some more writing tips, that build on the post, Words and writing .... Most of these I learned in high school (a very long time ago), as editor of the school paper. (And, yes, I still use them today.)

• My teacher taught us to vary the first letter of each paragraph, and start the paragraphs with interesting words (e.g., not "the", "this", "a", ...). Her point was that people got an impression of the article from glancing at the page, and the first words of the paragraphs made the most impression. If the words were boring, then the article was boring. I don't know if this is true, but it seems like a reasonable thing.
• Another good practice is to make sure your paragraphs are relatively short, so as not to seem overwhelming. (I try to keep my paragraphs under 5-6 sentences.) Also, each paragraph should have a clear focus and stick to it. It is difficult to read when the main subject of a paragraph wanders.
• Lastly, use a good opening sentence for each paragraph. It should establish the contents of the paragraph - setting it up for more details to come in the following sentences.

You can check out more writing tips at "Hot 100 News Writing Tips".

Andrea

Diagramming an RDF/XML OWL ontology

Over the course of time (many times, in fact), I have been asked to "graph" my ontologies to help visualize the concepts. Anyone who has worked with Protege (or the Neon Toolkit or other tools) knows that none of the tools give you all the images that you really need to document your work. I have often resorted to hand-drawing the ontologies using UML diagrams. This is both painful and a huge time sink.

Recently, I was reading some emails on the Linked Data community distribution list about how they generate the LOD cloud diagram. Omnigraffle is used in the "official" workflow to create this diagram, but that tool costs money to buy. One of the email replies discussed a different approach.

A gentleman from Freenet.de needed to draw a similar diagram for the data cloud for the Open Linguistics Working Group. His team could not use the same code and processing flow as the LOD cloud folks, since they didn't have many Mac users. So, they developed an alternative based on GraphML. To create the basic graph, they developed a Python script. And, ...

Using yed's "organic" layout, a reasonable representation can be achieved which is then manually brought in shape with yed (positioning) and XML (font adjustment). In yed, we augment it with a legend and text and then export it into the graphic format of choice.

Given my propensity to "reuse" good ideas, I decided to investigate GraphML and yEd. And, since GraphML is XML, ontologies can be defined in RDF/XML, and XSLT can be used to transform XML definitions, I used XSLT to generate various GraphML outputs of an ontology file. Once the GraphML outputs were in place, I used yEd to do the layout, as the Freenet.de team did. (It is important to note that the basic yEd tool is free. And, layout is the most difficult piece of doing a graphic.)

So, what did I find? You can be the judge. The XSLTs are found on GitHub (check out http://purl.org/NinePts/graphing). There are four files in the graphing directory:

• AnnotationProperties.xsl - A transform of any annotation property definitions in an RDF/XML file, drawing them as rectangles connected to a central entity named "Annotation Properties".
• ClassHierarchies.xsl - A transform of any class definitions in an RDF/XML file, drawing them in a class-superclass hierarchy.
• ClassProperties.xsl - A transform of any data type and object property definitions in an RDF/XML file, drawing them as rectangles with their types (functional, transitive, etc.) and domains and ranges.
• PropertyHierarchies.xsl - A transform of any data type and object property definitions in an RDF/XML file, drawing their property-super property relationships.

I executed the transforms using xsltproc. An example invocation is:

xsltproc -o result.graphml ../graphing/ClassProperties.xsl metadata-properties.owl

I then took the result.graphml and opened it in the yEd Graph Editor. (If you do the same, you will find that all the classes, or properties lay on top of each other. I made no attempt to do any kind of layout since I planned to use yEd for that purpose.) For the class properties graph (from the above invocation), I used the Layout->Radial formatting, with the default settings. Here is the result:

I was impressed with how easy this was!

The really great thing is that if you don't like a layout, you can choose another format and even tweak the results. I did some tweaking for the "Property Hierarchies" diagram. In this case, I ran the PropertyHierarchies.xsl against the metadata-properties.owl file and used the Hierarchical Layout on the resulting GraphML file. Then, I selected all the data properties and moved them underneath the object properties. Here is the result:

Admittedly, the diagrams can get quite complex for a large ontology. But, you can easily change/combine/separate the XSLT transforms to include more or less content.

With about a day and half's worth of work (and using standards and free tooling), I think that I saved myself many frustrating and boring hours of diagramming. Let me know if you find this useful, or you have other suggestions for diagramming ontologies.

Andrea

Words and writing ...

I came across an amazing blog entry today. I love reading and writing. When writing, I try to communicate my thoughts in a (hopefully) clear and entertaining manner. I often use dictionaries and thesauri to get ideas for new and different words, to spice up my paragraphs when they seem dull.

But, after reading the blog entry from James Somers, "You're probably using the wrong dictionary", I know that I have been fooled ("deceived; imposed upon") by my current tools.

Mr. Somers' blog discusses how Webster came to create the first dictionary, how John McPhee uses Webster's dictionary when creating his fourth draft of a work, and how dictionaries could come to inspire thought and writing. I know that you don't believe me on that last point ... so go check out The ARTFL Project (Webster's Dictionary, 1913 and 1828 editions). Enter any word that comes to mind and see what you find.

Here is my example, I entered the word, car (trying for a word that was mundane). Here is the text from the 1828 edition ...

1. A small vehicle moved on wheels; usually, one having but two wheels and drawn by one horse; a cart.
2. A vehicle adapted to the rails of a railroad. [U. S.] &hand; In England a railroad passenger car is called a railway carriage; a freight car a goods wagon; a platform car a goods truck; a baggage car a van. But styles of car introduced into England from America are called cars; as, tram car. Pullman car. See Train.
3. A chariot of war or of triumph; a vehicle of splendor, dignity, or solemnity. [Poetic].
   The gilded car of day. Milton.
   The towering car, the sable steeds. Tennyson.
4. (Astron.) The stars also called Charles's Wain, the Great Bear, or the Dipper.
   The Pleiads, Hyads, and the Northern Car. Dryden.
5. The cage of a lift or elevator.
6. The basket, box, or cage suspended from a ballon to contain passengers, ballast, etc.
7. A floating perforated box for living fish.

[U. S.] Car coupling, or Car coupler, a shackle or other device for connecting the cars in a railway train. [U. S.] -- Dummy car (Railroad), a car containing its own steam power or locomotive. -- Freight car (Railrood), a car for the transportation of merchandise or other goods. [U. S.] -- Hand car (Railroad), a small car propelled by hand, used by railroad laborers, etc. [U. S.] -- Horse car, or Street car, an ommibus car, draw by horses or other power upon rails laid in the streets. [U. S.] -- Mcol>Palace car, Drawing-room car, Sleeping car, Parior caretc. , (Railroad), cars especially designed and furnished for the comfort of travelers.

I was blown away! Webster's 1828 and 1913 dictionaries will become my new source of words (admittedly, not modern, but definitely poetic). Mr. Somers explains how you can download and install the 1913 edition, and use it in conjunction with your other dictionaries on your Mac, Kindle and iPad. That upgrade of my dictionaries is underway as I type.

Andrea

Ontology Summit 2014 and the communique

Ontology Summit 2014 officially concluded with the symposium on April 28-29. There were some great keynotes, summary presentations and discussions. You can see most of the slides on the Day 1 and Day 2 links, and can also check out the online, unedited Day 1 chat and Day 2 chat.

The main "output" of each Ontology Summit is a communique. This year's communique is titled Semantic Web and Big Data Meets Applied Ontology, consistent with the Summit theme. Follow the previous link to get the full document, and consider endorsing it (if you are so inclined). To endorse the communique, send an email to with the subject line: "I hereby confirm my endorsement of the OntologySummit2014 Communique" and include (at least) your name in the body of the email. Other remarks or feedback can also be included. And, I would encourage you to add your thoughts.

I want to provide a quick list of the high points of the communique (for me):

• In the world of big data, ontologies can help with semantic integration and mapping, reduction of semantic mismatches, normalization of terms, and inference and insertion of metadata and other annotations.
• Development approaches that involve a heavy-weight, complete analysis of "the world" are evolving to lighter weight approaches. This can be seen in the development of ontology design patterns, the use of ontologies in Watson, and the bottom-up annotation and interlinking approaches of web/RESTful services (as "Linked Services").
• There are some best practices that can be applied for sharing and reuse to succeed (and since I drafted most of these best practices, I am just copying them directly below :-)):
  • Wise reuse possibilities follow from knowing your project requirements. Competency questions should be used to formulate and structure the ontology requirements, as part of an agile approach. The questions help contextualize and frame areas of potential content reuse.
  • Be tactical in your formalization. Reuse content based on your needs, represent it in a way that meets your objectives, and then consider how it might be improved and reused. Clearly document your objectives so that others understand why you made the choices that you did.
  • Small ontology design patterns provide more possibilities for reuse because they have low barriers for creation and potential applicability, and offer greater focus and cohesiveness. They are likely less dependent on the original context in which they were developed.
  • Use "integrating" modules to merge the semantics of reused, individual content and design patterns.
  • Separately consider the reuse of classes/concepts, from properties, from individuals and from axioms. By separating these semantics (whether for linked data or ontologies) and allowing their specific reuse, it is easier to target specific content and reduce the amount of transformation and cleaning that is necessary.
  • RDF provides a basis for semantic extension (for example, by OWL and RIF). But, RDF triples without these extensions may be underspecified bits of knowledge. They can help with the vocabulary aspects of work, but formalization with languages like OWL can more formally define and constrain meaning. This allows intended queries to be answerable and supports reasoning.
  • Provide metadata (providing definitions, history and any available mapping documentation) for your ontologies and schemas. Also, it is valuable to distinguish constraints or concepts that are definitive (mandatory to capture the semantics of the content) versus ones that are specific to a domain. Domain-specific usage, and "how-to" details for use in reasoning applications or data analytics are also valuable. Some work in this area, such as Linked Open Vocabularies and several efforts in the Summit's Hackathon, is underway and should be supported.
  • Use a governance process for your ontologies (and it would be even better if enforced by your tooling). The process should include open consideration, comment, revision and acceptance of revisions by a community.
• Lastly, what are some of the interesting areas of investigation? One area, certainly, is the need for tooling to better support modular ontology development, integration, and reuse. Another is support for hybrid reasoning capabilities - supporting both description logic and first-order logic reasoning, and both logical and probabilistic reasoning. Third, tooling that combines data analytic and ontological processing would be valuable to make sense of "big data", and aid in the dissemination of the resulting knowledge to users and for decision support. To truly address this last area, it may be necessary to create specialized hardware and processing algorithms to combine and process data using the graph-structured representations of ontologies.

That's it for me, but please take a look at the communique, draw your own conclusions, and determine your own highlights.

Andrea

Updated metadata ontology file (V0.6.0) and new metadata-properties ontology (V0.2.0) on GitHub

I've spent some time doing more work on the general metadata ontologies (metadata-annotations and metadata-properties). Metadata-annotations is now at version 0.6.0. In this release, I mainly corrected the SPARQL queries that were defined as the competency queries. SPARQL is straightforward, but it is easy to make mistakes. I made a few in my previous version (because I just wrote the queries by hand, without testing them - my bad). Anyway, that is all fixed now and the queries are correct. My apologies on the errors.

You can also see that there is a new addition to the metadata directory with the metdata-properties ontology. Metadata-properties takes some of the concepts from metadata-annotations, and redefines them as data and object properties. In addition, a few supporting classes are defined (specifically, Actor and Modification), where required to fully specify the semantics.

Actor is used as the subject of the object properties, contributedTo and created. Modification is designed to collect all the information related to a change or update to an individual. This is important when one wants to track the specifics of each change as a set of related data. This may not be important - for example, if one only wants to track the date of last modification or only track a description of each change. In these cases, the data property, dateLastModified, or the annotation property, changeNote, can be the predicate of a triple involving the updated individual directly.

It is important to understand that only a minimum amount of information is provided for Actor and Modification. They are defined, but are purposefully underspecified to allow application- or domain-specific details to be provided in another ontology. (In which case, the IRIs of the corresponding classes in the other ontology would be related to Actor and Modification using an owl:equivalentClass axiom. This was discussed in the post on modular ontologies, and tying together the pieces.)

Also in the metadata-properties ontology, an identifier property is defined. It is similar to the identifier property from Dublin Core, but is not equivalent since the metadata-properties' identifier is defined as a functional data property. (The Dublin Core property is "officially" defined as an annotation property.)

To download the files, there is information in the blog post from Apr 17th.

Please let me know if you have any feedback or issues.

Andrea

General, Reusable Metadata Ontology - V0.2

This is just a short post that a newer version of the general metadata ontology is available. The ontology was originally discussed in a blog post on April 16th. And, if you have trouble downloading the files, there is help in the blog post from Apr 17th.

I have taken all the feedback, and reworked and simplified the ontology (I hope). All the changes are documented in the ontology's changeNote.

Important sidebar: I strongly recommend using something like a changeNote to track the evolution of every ontology and model.

As noted in the Apr 16th post, most of the concepts in the ontology are taken from the Dublin Core ELements vocabulary and the SKOS data model. In this version, the well-established properties from Dublin Core and SKOS use the namespaces/IRIs from those sources (http://purl.org/dc/elements/1.1/ and http://www.w3.org/2004/02/skos/core#, respectively). Some examples are dc:contributor, dc:description and skos:prefLabel. Where the semantics are different, or more obvious names are defined (for example, creating names that provide "directions" for the skos:narrower and broader relations), then the purl.org/ninepts namespace is used.

This release is getting much closer to a "finished" ontology. All of the properties have descriptions and examples, and most have scope/usage notes. The ontology's scope note describes what is not mapped from Dublin Core and SKOS, and why.

In addition, I have added two unique properties for the ontology. One is competencyQuestions and the other is competencyQuery. The concept of competency questions was originally defined in a 1995 paper by Gruninger and Fox as "requirements that are in the form of questions that [the] ontology must be able to answer." The questions help to define the scope of the ontology, and are [should be] translated to queries to validate the ontology. These queries are captured in the metadata ontology as SPARQL queries (and the corresponding competency question is included as a comment in the query, so that it can be tracked). This is a start at test-driven development for ontologies. :-)

Please take a look at the ontology (even if you did before since it has evolved), and feel free to comment or (even better) contribute.

Andrea