Worries
- end-to-end applications
- what can we do with DAML content?
- hope for 3-5 design patterns each for communication (central KB, distributed queries, asynchronous agent communication, ...)
and processing (Java direct model manipulation, Prolog rules, ...)
- scalability
- can current tools handle even the 2.5M statements collected by the
DAML Crawler?
- 2.5M statements is large for XML, but trivial by DBMS standards
- performance
- processing of a locally-stored file on an 800 MHz laptop with 256MB RAM
Content |
researchers.daml |
royal92.daml |
geofile.daml |
Size (bytes) |
22,375 |
1,128,202 |
33,709,229 |
DAML+OIL Statements |
397 |
29,657 |
800,220 |
Java file I/O (secs) |
0.20 |
0.33 |
4.17 |
Java SAX XML (secs) |
0.44 |
0.76 |
6.76 |
RDF API 2001-01-19 (secs) |
2.81 |
9.43 |
280.04 |
Jena 1.1.0 (secs) |
0.78 |
4.35 |
8315.13 |
Redland (repat) 0.9.8 (secs) |
0.04 |
5.73 |
324.28 |
- memory usage is also a problem,
geofile.daml requires
java -Xmx512m
- initial
results
with
Quantify
indicate that most of the time is being spent in garbage collection and
(other) layering overhead
- operational integration of DAML into an existing XML application
- DAML uses XML, so this sounds easy in theory
- John Flynn and an intern have been working on
DAML-HR
- using a resume DTD from the
HR-XML Consortium
- expect to demonstrate the value added by DAML+OIL
- shows XML/DAML coexistence and
(potentially) use of XML as a stepping stone to DAML