Public:Ontology Summary

From Facade

Jump to: navigation, search

This collects information about the Project Information Model (PIM) RDF ontology, used to create metadata about archival objects.

Here the word "Project" signifies the project to design and construct a building--this is what we have modelled the information about.


Contents

Remarks on the Ontology

Building design generates a very large number of digital files. These files are the result of the process of design and construction for an architectural project. Organizing these files and preparing them for consumption involves sorting them into the kinds of informational resources they compose, recording descriptive metadata about the resources, and identifying resource relationships. The framework for this organization we call the Project Information Model or PIM. The PIM contains definitions for the resource kinds, metadata, and relationships.

The Project Information Model takes the form of an ontology for the domain of an architectural project digital archive. The ontology is defined in two documents--a Class Diagram showing all the resources within the PIM and their relationships, and a "Web Ontology Language" (OWL) document that contains RDF declarations for each class of resource in the ontology and every property assigned to them.

Standards and Downloads

Namespaces

It is essential that documents are written with the same URIs that the applications expect. RDF URIs are usually abbreviated with namespaces. Here are the ones shared by all PIM documents:

PrefixURIcomment
pimhttp://libstaff.mit.edu/facade/images/c/c4/pim.owl#
dctermshttp://purl.org/dc/terms/W3C standard
project http://facade.mit.edu/dataset/project-name/ Suggestion only; any unique URI prefix works.

Notes

  1. All PIM objects that are part of a given project must be identified by URIs in the same namespace. The namespace URI itself may be anything; the example given above is just one suggestion for a convention to follow.

    The reason for this requirement is that tools must be able to generate additional unique URIs by looking at the body of URIs already in the namespace, and perhaps a unique-id counter bound to the pim:Project object.


Current Version of PIM OWL (v2.7.1)

Links to the versions of the OWL (Web Ontology Language) file for the FACADE PIM are found here.

This is the formal definition of PIM in W3 OWL.

Current Version of Class Diagram (v2.7.1)

09 February 2009

Earlier Versions of OWL

Version v2.5.1: Rob Wolfe, 8 December 2008

Adjustments to this version:

The pim:File class has been properly designated as a subclass of pim:ProcessedObjects.

The pim:Directory class has been properly designated as a subclass of pim:ProcessedObjects.

The pim:Software class has been created. This new class is intended to allow us to better define the software packages that are used to create derivative objects. It is little more than a placeholder no for future development (during the 3rd prototype phase) and has no properties at this time.

The pim:derivedBy property of the pim:File class is now an ObjectProperty with the new pim:Software class as its range.

The name of the pim:DesignSet vocabulary class has been changed to pim:DesignDrawingSet in order to comply with the naming convention used in the Design Type vocabulary.

Added pim:DT_Garbage to the Document Type vocabulary.

Version (v2.5): Rob Wolfe, 4 December 2008

This definition incorporates the Classes, Objects and Properties from the "PIM Extras" Ontology document. These extra declarations create a Controlled Vocabulary superclass to organize the properties common to the classes that define controlled vocabularies for the "Five Properties" that are to be applied to all Files. In adding these classes, changes were made to the vocabulary values, which are instances of each of the vocabulary classes. These value names were all prefixed according to the vocabulary to which they belonged in order to avoid URI clashes in this Ontology. This version also adds rdfs:label attributes to all Classes and Properties. In this version the "Digital Object" superclass has been renamed to "Design Object" and its subclass "Output" has been renamed to "Presentation".

Still Earlier Versions

Earlier version Rwolfe 6 October 2008

This definition incorporates Larry Stone's edits and additions and brings the OWL document into agreement with the class diagram. It includes all vocabulary terms identified to date during the building of the dataset for demo two.

Earlier version lcs 3-Sep-08

Earlier version Rwolfe 4 August 2008

This definition is consistent with the 4 Augst iteration of variation 1 ONLY of the class diagram.

Earlier version Rwolfe 30 July 2008

This definition is consistent with the 30 July 2008 iteration of variation 1 ONLY of the class diagram.

Earlier version Rwolfe 21 July 2008

This definition is consistent with the 21 July 2008 iterations of variations 1 and 2 of the class diagram.

Earlier Versions of Class Diagram

  • The ontology class and properties diagram is posted in this section.

Version (v2.5.1): Rob Wolfe, 8 December 2008


This image 1,000px wide. [Access 3,120px original.]

  • This version now reflects the changes made to version 2.5.1 of the Ontology Document and listed above. It also now accurately reflects that several properties are actually in the domain of superclasses and inherited by subclasses.

The pim:phase, pim:format, pim:zone, pim:documentType, pim:architecturalDiscipline properties are all within the domain of the pim:PreservationObject class. This means that they are applicable to the instantiated subclasses pim:Design, pim:Presentation and pim:File.

The pim:hasFile, pim:hasIndex, and pim:hasDisplay properties are all within the domain of the pim:DesignObject class. This means that they are applicable to the instantiated subclasses pim:Design and pim:Presentation.

The changes to the Class Diagram amount to the adjustment of blue and red dashed lines that originate from the true domains, that is the pim:DesignObject and pim:PreservationObject classes and not the instantiated subclasses that inherit the properties. The change make the diagram a cleaner and more accurate depiction of the PIM Ontology.

Version (v2.5): Rob Wolfe, 4 December 2008

Media:facadeontv2p5.png

  • This version now includes the pim:ControlledVocabulary superclass and its subclasses, as well as the DesignType and FormatCategory vocabulary classes.

Still Earlier Versions

This version now includes the pim:Directory class, a processing class whose instances will not be presented to the public. It also contains corrections to the namespaces and content types of properties, notably the properties of the pim:Project, pim:PreservationObject, pim:File, and pim:ProcessedObject classes. Those properties that link objects in thei PIM are distinguished from those properties that have vocabularies controlled by Object declarations in the PIM

Media:facadeontv2p4.jpg

This version now contains three superclasses (Digital Object, Display Object and Processed Object). All conflicts in the use of the word "presentation" have been resolved. The model and drawing classes have been collapsed into one Design class. File properties have been separated out into two superclasses: Display Object, for those properties we will likely present via the UI and Processed Object, for those properties we need to make the CWB go, but do not intend to share with the public. Properties relating Digital Objects to each other have been renamed to be more sensible (isDrawingOfPartOf and isOutputOf).

Media:facadeontv2p3.jpg


This version of this iteration contains two superclasses (Digital Object and Presentation Object). There are four subclasses: Drawing, Model and Output are all subclasses of both Digital and Presentation Object. Project File is a subclass of Presentation Object only. This is how Presentation and Preservation properties are separated. All preservation properties belong to the Project File class. All Presentation properties belong to the Presentation Object Class. The Digital Object class and its subclasses contain properties that allows Project Files to be aggregated into Digital Objects that we wish to highlight in our exhibits. I did not combine the Model and Drawing Classes into one Design Class as there is a distinct relation between the two that needs to be identified. I added a relationship between the output and model classes.

Media:facadeontv2p2.jpg

This version contains a class declaration for a model, which would be one 3D model for the entire building or project. It also contains a class declaration for a model part, that is a 3D model for just part of a building or project. Both classes assume that instances will contain references to actual files.

Earlier iteration of variation 1 (21 July 2008).

Media:facadeontv2p1.jpg

Earlier iteration of variation 1.

Media:facadeontv2.jpg