Here are some important things to remember while using the DAML+OIL plug-in.
Only the XML Schema Datatypes are supported. You cannot extend the XML Schema Datatypes nor declare user-defined data types. You may define your own classes and use these classes in a similar way to datatypes, however, much of the syntax used to define datatypes is not actually a part of the DAML+OIL syntax. For this reason, user defined datatypes and extensions to existing datatypes are not supported.
Due to restrictions in the Protege system, the maximum cardinality of each slot has been set to 1000. We know that this is not a very robust method for providing you with multiple cardinality, however, we are unable to give you unrestrained multiple cardinality at this time without exposing too much complexity to the user. If it is of dire importance that you be able to fill an instance with more than 1000 values for a property then contact us and we can go about showing you how to do so in the plug-in.
You must include a default namespace in your ontology. For example:
If you include no default namespace the plug-in will provide one for you "http://unspecifiedDefaultNamespace" and you will be able to change this when you go to save it. It is best to always give a default namespace in your ontology, though.
Since the DAML+OIL plug-in is dependent upon the ARP parser it is unable to handle certain namespaces. The reason for this is that within RDF, URI references are absolute. While any string may technically be a URI, the ARP parser will only allow us to parse DAML+OIL Ontologies where the namespaces given indicate absolute URI's.
For this reason, we recommend that all Namespaces begin with "http://" for now. Other namespaces will parse right now, but they show up oddly in the GUI (a bug we hope to take care of soon). Very shortly we will post a more thorough outline of the legal namespace syntax the plug-in will work with.
For a complete resource on URI syntax see: Uniform Resource Identifiers (URI): Generic Syntax
Also please be advised that it is best to end a namespace with a hashmark '#' to help the parser tell where a namespace is ending and the local name begins. There is not yet any kind of standardized way of doing this, and the parser will be able to deal with the namespace without it. However, there are a couple of potentially sticky situations that one might run into if it is not there, so if you are having difficulties that might be namespace related, try adding a hashmark at the end of the namespace.
(NEW) Aside from the default namespace, namespaces cannot be edited in the plugin. The plugin will automatically abbreviate namespaces to make the daml output easier to read, but the namespace itself and the exact abbreviation that is used for it cannot be accessed by the user or altered in any way.
This is currently unavailable.
(NEW) Imports are used typically to allow you to access the resources defined in other location. For example, you might write a ontology in which you would like to use some concepts of time and so you might import the Daml Time ontology. (http://www.ai.sri.com/daml/ontologies/time/Time.daml) Our plugin does NOT support this. You cannot reference resources that are in other locations anywhere in the onotologies you read and author in Protege. If you have a reference to a resource in your ontology that resource must be defined in that same ontology. There are exceptions for the following locations:
Note: This refers to the DAML tag <imports> which is used to reference another DAML+OIL ontology containing definitions that apply to the current DAML+OIL resource. This aspect of DAML+OIL syntax is currently not treated in our plug-in. This is not to be confused with the command Import in the Project menu which is used to open DAML+OIL ontologies. That command is fully functional and is the ONLY way to access your ontologies.
Multiple Range or Domain specifications in Protege are understood as a union, whereas a DAML+OIL property with multiple domain or range specifications is understood to have the intersection of all specified elements as its range. Therefore in the current release multiple domain and range specifications are not properly treated.
These are currently unavailable
When you select a Slot from the damlProperties field of a class you see something like this:
There are two view buttons that you can select
You should always view the top level slot. Editing the slot at the class level alters the facets on the slot. (Facets are like restrictions. They are a OKBC concept. Learn more here.) The plug-in doesn't deal with facets as stated below, so it's best not to touch them. Changing the slot at the top level has the proper effect.
Changing facets or defining new ones will have an effect on the classes and slots in Protege, but will not persist through serialization. It's best not to alter them at all.
These are not currently supported