Lines Matching defs:the
13 \title{Design and Notes for the \CASLDL Node in Hets}
17 \textbf{Note:} The following issues very often mention the not jet
18 complete OWL DL logic (node) of Hets. Clearly the development of
24 the named spec is put into a file/CASL library that contains
25 only this named spec? Till] [No, if you parse an OWL DL file the
27 specifications. This makes the handling of parsing and analysis
32 food.owl. If you parse wine.owl the parser reads first wine.owl and
34 hence it skips the import in food.owl. This development graph has
41 [Although it seems to be the only way, it sounds a bit complicated.
42 Perhaps you could leave out the ``splitting back'' in a first
45 Where do we get the name from:
47 \item Name derived from URI of the OWL DL-File.
50 \item (Given as annotation to the Ontology in the OWL DL-File.)
55 which seems not to be the case. Till ] Do we generate OWL DL-files
65 abbrev for the disambiguation when an imported ontology is extended)
67 How to treat circlar imports in the development graph.
69 cyclic imports are not supported, unless the theories
74 the document inherent base URI which is seen as the URI of the
78 Annotations (on the OWL DL side) can point to parts that are
79 extensions. \emph{not in the paper}
88 \subsection{Structuring on the \CASLDL side}
90 DL file. After conversion back from spme genrated OWL DL files the
91 structuring is lost. (or we have to add many Annotations to the
101 \item new FORMULA variants, that have directly the semantics of
102 Cardinality Restrictions. No tracing is needed. Only the the
103 embedding into \CASL is a little bit harder, as the instantiation
116 the right place, need they still be in the \CASLDL-Signature?
121 have all annos available during the analysis.
123 have all annos available during the analysis.
127 eases things? Other OWL tools also should have the problem
129 unification is done by the parser we currently consider, but all
135 we want shorter ids than URIs. So we could use the last part of each
137 unique. We could either use the name of the specification (OWL DL)
139 the namespace abbrevs generated by the OWL DL parser could be
141 \CASLDL and translated to OWL DL the declaration of symbols is
150 \item Namespace abbrevs are added as prefix to the Identifier with an
151 underscore only if needed for distinction and the real mapping of
156 [I vote for the second possibility, because it keeps names shorter
167 On the OWL DL side so called AnnotionProperties can be declared and
169 with the other AnnotationProperties?
183 on the OWL DL side like ordinary other properties. And they are
184 applied like other properties. We have no place in the Signature yet
186 [Sounds strange to me. But if this the way OWL DL works, we have
199 mapping URIs to abbreviations that are kept during the translation
200 from and to OWL DL and that are used in compounds for the distinction
209 an URI and file path. The URI is used as the base URI of the xml (owl)
214 OWL allows the declaration of untyped annotation properties. They can
215 be applied to all symbols / entities like the ontology as a whole and
229 CID is a \CASL Id that must be declared in the current specification (library).
233 INDIVIDULA-ID is the Id of a declared constant operation.
241 literal denoting the number of relations for each member of the
253 \item Namespace abrreviation maps (maybe better as part of the
266 \SId{GenCardinality} from the WADT04 paper.
268 Theories of the known datatypes where all the opearations are hidden
269 except those needed for the construction of literals. These datatypes
270 are than collected under the supersort \Id{DATA}
276 A specification that embeds the \CASL specification of predefined
288 all and apply something behind the scenes to get the mixfix and static
289 analysis working with the predefined stuff visible.
291 [I would vote for the first possibility. In CASL, there are no
293 CASL-DL. Till] [This complicates checking the CASL\_DL language. Every
294 renaming of the predefined OWL DL datatypes and Symbols must be