Start with the collected results of homework assignment 1, augmented, if desired, by hypothetical DAML repositories of your own choosing.

Propose 5 queries of roughly increasing complexity that might be performed on any or all these data sets. Queries can be expressed in English, predicate calculus, and/or other suitable representations.

1. Give me the entry dates, names, and descriptions of all open milestones for a given project, ordered by entry date, plus the names and entry-dates of the open to-do items that relate to them.

Describe how you would expect these queries to be implemented. Identify the major DAML software components and sketch (in text, HTML, PowerPoint, GIF, or JPEG) the control and data flow among them. Your solution may address some or all of the following topics, query language, dynamic retrieval, crawling, cacheing, translation, inference, scalability, consistency, security, ...

The final, interactive version of WebScripter needs access to both the ontologies (pre-tripelization) to guide the user in constructing the query, as well as access to data (post-tripelization) to efficiently executing the query.

As far as DAML ontologies are concerned we propose:

DAML source pages on the Web
        |
AltaVista-like crawled index of ontology DAML pages (not triples!)
        |
WebScripter

As far as DAML data is concerned we propose:

DAML data sources on the Web
        |
on-demand puller or pre-run crawler
        |
database that can handle millions of triples
        |
WebScripter

Consider how this could be accomplished if some of the DAML content was sensitive information stored on multiple WWW sites protected by passwords and/or certificates. You may or may not have access to all of the data.

What we envision is that there is a per-user collection of their passwords and certificates. WebScripter queries then run against the combination of the (probably crawled) public database and the (possibly crawled) per-user database of protected information.

WebScripter currently already tags every triple it reads with the URL it came from (by running a loop of rdfapi calls on a per-input-URL basis). It could similarly tag the security status of every triple so that the DAML version of the WebScripter report output can carry through the appropriate security tags (or omit secure output alltogether).

We have a very real security issue with our current WebScripter data - our project milestones, to-do items, and status are essentially publicly available to the world on a real-time basis right now (the only thing that protects them is "security by obscurity"). We would like to be able to share all of our data with certain parties (such as the subcontractors for our ANTS project), and just selected information with the rest of the world (e.g. our project descriptions and their rough status without the detailed internal discussions and to-do items). However, unless otherwise directed, we will not address these security issues on our own and instead focus on our core interactive-WebScripter-reports effort.

Extra Credit: Develop software to implement any or all of 3.

We have fully implemented the first query as stated above (URL for the output also above).

The software we have is a report instantiator that takes an XML definition of a report definition and fills it with data. It operates on top of Melnik's RDFAPI and works exclusively on the triplized data. The content of every colummn to the right is computed from the content to the left (the first column that seeds the rows in the table is a special case - it specifies the type of instance that creates a row).

We believed we could put up a servlet that takes a WebScripter report definition and fills it with data by today (2000-12-15) but did not make it, but it should be up before the end of the year (we will announce it separately). It will offer a library of WebScripter reports that can be run as they are, or can be downloaded, modified, put on an arbitrary Web server, and then run from there (by posting the URL of the modified report definition to an HTML form on our Web site).

Based on your architectural sketch in 3, propose any new entries to be added to the Tools Wishlist.

We don't believe anything on our wish list is novel, but there is probably some value in tabulating what every group is asking for, so here it is:

A Database that does very fast pattern matching against triples, and scales to a numberples that would not fit into main memory.

A Crawler that munges all DAML content known to mankind and deposits it into the above database. WebScripter report definitions currently explicitly list every DAML source URL that should be loaded - practical for our internal use of WebScripter for project management but obviously impractical for searching the Web at large for content.

A DAML ontology validator that takes an ontology file and data files (separately) and reports on what in the latter is lacking with respect to the former. We have defined nine DAML ontologies so far, but they are all rather "flat" and rarely specify required cardinalities and data types as doing so is not very gratifying without being able to use them for validation.

Discuss any lessons learned or insights gained from this assignment.

One experience over the last weeks is that the most error-prone part of specifying WebScripter report definitions is in mistyping a character or two in strings that should match a subject, predicate, or object of a triple. The most practical solution (for hackers) in working with RDF source files is to redirect all of the triples to a file and then copying and pasting the right strings to the WebScripter report definition. We are scheduled to make WebScripter reports be interactively producable in the second semester of our effort.

Post the homework results on your public project page, and send the URL to webmaster@daml.org.