Some folks on the Joint EU/US Committee on Agent Markup Languages have been asking about what "tag" means in the context of "tagged" logics. This is probably my fault, I introduced the term to the discussion, precisely because I wanted a certain ambiguity -- there are a number of different schemes for specialized "logic about logic" ranging from formal models of "annotated logics" (Kifer and Subrahmanian, cite from Google when I can find it) to complex higher-order models (like the PCA work Dan and Tim keep pointing to - ref from Google). In the middle, are schemes where some specific information is added to every node. Thus, for example, in SHOE we have what we call a claims logic in which every assertion is given an additional field which is the URI where that fact was asserted (for details see http://www.cs.umd.edu/projects/plus/SHOE/pubs/#tr99 - section 2.3).
Annotated logics are primarily used in logic-programming languages. The basic idea is that each statement is tagged with arguments to one or more functions -- any arbitrary monotonic functions in the most general case (Kifer,Subrahmanian). For each way two statements can be combined, the function can be computed - since there's a small number of ways these things combine, the function can be expressed for all logically permissible possibilities. Annotated logics have been used for belief systems, probabilities, temporal reasoning and a number of other applications.
You know what these are - key idea is that logic statements can refer to other logic statements, i.e. (Believes John (believes Fred (believes Sam (Isa WebHacker Dan)))). These can be used for a lot of things, but it turns out that history has proven that many higher-order logics can be replaced by simpler schemes (this was the motivation for annotated logics as I understand it.)
In RDF-based languages (like DAML+OIL) the general idea of any kind of tagging scheme is to extend the triples to n-tuples, with some additional fields. Some tags that have been proposed are:
The general problem with these tag schemes is that they leave it to the language designer to prescribe the tags and describe how they work. Rarely, if ever, have they come with good formal logics (model theoretic or axiomatic) - operational logics are more common. The main benefit of these kinds of schemes is they allow many of the advantages of a higher-order logic, but for a much more limited domain. Further, they don't require the tremendous computational overhead that higher order logics need (example, PCA would have serious scaling problems - Felten, personal communications).
Annotated logics have many advantages, but one main disadvantage - one needs to be a pretty good logician to understand/design a good function and use it appropriately. Further, they generally would not be applicable (or at least correct) in the presence of logical inconsistency and/or the kind of pathologies shown in http://www.cs.umd.edu/users/hendler/jhendler.daml (you may need to view source).
Higher-order logics may eventually be needed, but in practice they have added marginal utility for the additional computational burden.
Tagging schemes have the general problem that if one allows arbitrary tags, then there is no way to know the semantics attached to the tag. But wait! Remember that this is the general problem we are designing ontologies to solve.
So here is the bones of a suggestion -- we derive a scheme in which a semantic web document can both express the ontology of the terms it uses (directly or by URI) as well as the tags it uses (again, in the file itself or by URI reference). Thus, the parser reading the file could recognize that it will need an N-tuple, where N is 3 (for RDF) + the number of tags. Further, the definition of the tags is done in DAML+OIL itself.
Thus, for example I could define a class called CLAIM-TAG which is of type URI. A tool designer, seeing I pointed to such a class, would know to allow an extra field for this (and to make it of this Type if it is a data-type). Combining the tags would still be done procedurally, and thus either a logic for a particular type of tag would need to be defined (ala annotated logic), or the tool designer who wanted to use these tags would need to know how they are used.
What is the advantage to this scheme? A "mix and match" approach to tag schemes could be defined. Thus one person could design an ontology, another could define a tag scheme. A document could say I use Ontology X with tag scheme Y, and those tools that were "tag aware" could do more than those that were just "ontology conscious." Market forces could determine best types of tags -- but still publish the tag scheme data in a machine-readable "semantic web friendly" sort of way.
(possibility: tags could include sub-tag information ala structure definitions -- i.e. TIME-TAG = Date-tag | Time-Stamp)
Jeff works out the details and tells me why it won't work, and how to fix it.