Loading source files for package notio...
Loading source files for package notio.translators...
Loading source files for package notio.test...
Constructing Javadoc information...
/home/finnegan/code/src/notio/translators/LFParser.java:6: Class com.metamata.parse.ParseException not found in import.
import com.metamata.parse.ParseException;
^
/home/finnegan/code/src/notio/translators/CGIFParserImpl.java:7: Package com.metamata.parse not found in import.
import com.metamata.parse.*;
^
/home/finnegan/code/src/notio/translators/CGIFParserImpl.java:241: Superclass com.metamata.parse.Scanner of inner class notio.translators.CGIFParserImpl. __jjScanner not found.
public class __jjScanner extends com.metamata.parse.Scanner {
^
/home/finnegan/code/src/notio/translators/CGIFParserImpl.java:311: Superclass com.metamata.parse.ScanError of inner class notio.translators.CGIFParserImpl. __jjScanner.TokenMgrError not found.
class TokenMgrError extends com.metamata.parse.ScanError
^
/home/finnegan/code/src/notio/translators/CGIFParser.java:6: Class com.metamata.parse.ParseException not found in import.
import com.metamata.parse.ParseException;
^
List of @bug Tags
List of @bug Tags
Package Index
Method Comments
- Method conformsToType(notio.ConceptType)
- Should probably test for subtype as well.
Method Comments
- Method removeTypeFromHierarchy(notio.Type)
- Should TypeRemoveError be TypeRemoveException instead?
- Method computeTypeLevels()
- Just here as an experiment.
Method Comments
- Method replaceTypeInGraph(notio.Graph, notio.RelationType, notio.RelationType)
- This method does nothing at present since it would need a setType() method in
Relation and that has not yet been decided upon.
Class Comments
- Must rework all matching-related comments.
Method Comments
- Method matchNameDesignator(notio.NameDesignator, notio.Designator, notio.MatchingScheme)
- Should case-sensitivity be a static instead?
- Method isEquivalentTo(notio.Designator, notio.Designator, notio.MatchingScheme)
- What about LambdaDesignators?
- Compare sets.
- Method matchDesignators(notio.Designator, notio.Designator, notio.MatchingScheme)
- What about restriction matching against unbound lambdas?
- Does the restriction/generalization/equivalent terminology makes sense here?
Equivalent doesn't really seem to be correct here.
- MATCH_INDIVIDUAL can be applied to designators other than MARKER (eg. LITERAL).
Class Comments
- This class does nothing. What are these things for anyway?
Class Comments
- Should this be in the API or not?
Method Comments
- Method setType(notio.ConceptType)
- What about type-checking in relations.
- Method isolate()
- This should be done in some cleaner way, either in Graph or some other way here.
- Method getRelators()
- Should this method be in Graph instead?
- Method restrictTo(notio.ConceptType)
- Need to rethink restricts.
- Method restrictTo(notio.Referent)
- Need some method to check whether one designator is
more specific than another. Could be tricky with descriptors if
we want to get fancy.
- Method restrictTo(notio.ConceptType, notio.Referent)
- Need some method to check whether one designator is
more specific than another. Could be tricky with descriptors if
we want to get fancy.
- Method matchConcepts(notio.Concept, notio.Concept, notio.MatchingScheme)
- Should add specified quantifier matching too.
- Method matchSingleConcepts(notio.Concept, notio.Concept, notio.MatchingScheme)
- Should add specified quantifier matching too.
- Currently if doing type matching, if either type is 'null' then the match always
works. This might need to be a matching scheme flag instead.
- Must change comments to reflect use of MatchResult.
Class Comments
- What methods should generators be forced to implement.
Class Comments
- Needs to be upated to support actors and nested matches.
- Currently assumes that mappings of different node types can not affect each
other. This may not be true if coreferent matching is used on compound graphs.
- Folding probably requires that folded nodes match. The current method is
that they just have to match the same node in another graph but they should match
each other too, I think. This is not necessarily true, unless one can reduce
the folded nodes to entities which are not the same. For example: Mapping both
[Canine] and [Female] to [Bitch] is quite legal. However, [Canine#12] and [Female#44]
should probably not be allowed.
- Need to test folding.
- Need to add common subgraph stuff.
- Need to fix proper subgraph implementation and restrictions.
- Some types of relation matching might preclude the need for mapping related
concepts. Unrelated concepts (unconnected) will have to be mapped, of course.
- Arc-concept matching is very useful for the match routine in Relation but
rather poor for this level. Is there a way to reconcile the two without overly
complicating life?
Constructor Comments
- Constructor NodeMappingGenerator(notio.Graph, notio.Graph, notio.MatchingScheme)
- Actor mapping flag is currently hardcoded out.
- Constructor NodeMappingGenerator(notio.Graph, notio.Graph, notio.MatchingScheme, boolean, boolean)
- Reconsider assumption about ditching mappings given the non-existance of a
matched node type. Some of this is caught back in Graph.matchGraphs() with the checks
for empty graphs. Some conditions encountered here could produce a trivial matching.
Method Comments
- Method violatesSizeConstraints(boolean, boolean)
- Are the size constraints on subgraphs realistic? The answer is no!
- Method getNextFixedMapping()
- This method could be rewritten to store mappings so they are not regenerated
while creating permutations of different node type mappings.
- Method nextNodeMapping(notio.Node[], notio.Node[], int[][], int[], int[], int[], int, int[], int[], notio.Node[], notio.Node[], int, int, boolean, boolean)
- Requirement method doesn't work for proper subgraphs since we are allowed to
completely use 2 out of the 3 types of nodes. Probably have to use some higher
level control.
Class Comments
- Must add default class-wide setting for allowIncompleteRelations.
Method Comments
- Method addRelation(notio.Relation)
- Should check that valence is correct. Better done in Relation.
- Method replaceConcept(notio.Concept, notio.Concept)
- Should review the coreference stuff for this. Does removal need to be deeper?
- Method getContextGraph()
- Should this be called getEnclosingGraph() instead?
- Method expandConceptType(notio.Concept)
- Should we throw an exception if there is no type definition?
- Method expandConceptType(notio.Concept[])
- Should we throw an exception if there is no type definition?
- Method expandConceptType(notio.ConceptType)
- Should we throw an exception if there is no type definition?
- Method expandRelationType(notio.Relation)
- Should we throw an exception if there is no type definition?
- Method expandRelationType(notio.Relation[])
- Should we throw an exception if there is no type definition?
- Method expandRelationType(notio.RelationType)
- Should we throw an exception if there is no type definition?
- Method join(notio.Graph, notio.Concept[], notio.Graph, notio.Concept[], notio.MatchingScheme, notio.CopyingScheme)
- Need to examine the copy operations especially with regard to coreference.
- Need to use newInstance() to construct graph.
- Method matchGraphs(notio.Graph, notio.Graph, notio.MatchingScheme)
- What about MATCH_INSTANCE and null graphs? Should use equals() instead of ==.
- Method matchStructures(notio.NodeMapping)
- Currently forces arcs to be in order.
Class Comments
- Need to rework some actor-related comments.
- restrictTo() and copy() can only return a Relation, not an Actor. Perhaps
it can check the class to make sure that the correct class is used for the copy.
- Do we really want package visibility for member vars?
- Really need to rethink this whole input/output argument approach.
Constructor Comments
- Constructor Relation()
- Should the default be monadic rather than 0-adic?
Method Comments
- Method setArgument(int, notio.Concept)
- What about adjusting if there is a null type?
- Method setInputArgument(int, notio.Concept)
- What about adjusting if there is a null type?
- What if the index is out of range of the input args?
- Method setOutputArgument(int, notio.Concept)
- What about adjusting if there is a null type?
- What if the index is out of range of the output args?
- Method substituteArguments(java.util.Hashtable)
- Should we expose this in the API?
Constructor Comments
- Constructor Actor()
- Should the default be monadic rather than 0-adic?
Class Comments
- The semantics of whether an operation can return a mapping or not need to be
tightened a trifle. Is there any point to allowing empty mappings?
Constructor Comments
- Constructor RelationType()
- Must check whether undefined/unlabelled types break anything.
Method Comments
- Method matchRelationTypes(notio.RelationType, notio.RelationType, notio.MatchingScheme)
- Should really check to see if the two types belong to the same hierarchy, no?
Class Comments
- What about activating different features for separate,
concurrently running databases? Allow specific extensions instances?
Method Comments
- Method activateExtension(java.lang.String, java.lang.Object[])
- Should this throw OperationException so people can specify their
own errors?
- Method deactivateExtension(java.lang.String, java.lang.Object[])
- Should this throw OperationException so people can specify their
own errors?
Class Comments
- Coreference matching should be better structured. Currently automatch means that two
concepts will automatically match if they are coreferent. Coref agreement mean
that when matching two concepts, all of their coreferent concepts must match as well.
Should also be usable
to test that two graphs possess identical coreference structure. Perhaps
the current meaning should be a set of CN_ flags or a new set of REFERENT flags
should be added. Then the COREF_ flag could take a meaning similar to the ARC_
flag (i.e a requirement for identical structure).
- ARC flags and CONN flags may conflict in some ways.
- Instance matching is too implementation specific. It is based on the assumption
that two calls to Graph.getConcepts(), etc. will result in the same set of objects.
This need not be the case. We should probably override the .equals() method in
various classes to detect whether two different objects in fact represent the same
node within a given graph (compare graphs and place in graph, if no graph, use
Object.equals()).
Method Comments
- Method addMarker(notio.Marker)
- Do we need to check if the marker is already in the table?
It should never happen, but perhaps it would best.
- Method getNextAvailableMarkerID()
- Is this no longer necessary since we no longer allow addition of IDs to the table?
- Method setMarkerIndividual(java.lang.Object, notio.Marker)
- Should this throw an exception?
Method Comments
- Method addCoreferentConcept(notio.Concept)
- Should add a check to see the concept is already in this set.
Constructor Comments
- Constructor ConceptType()
- Must check whether undefined/unlabelled types break anything.
Method Comments
- Method matchConceptTypes(notio.ConceptType, notio.ConceptType, notio.MatchingScheme)
- Should really check to see if the two types belong to the same hierarchy, no?
Method Comments
- Method getOccurranceMessage()
- Does not give information about expected tokens.
Method Comments
- Method isContext()
- Should probably include the non-blank condition.
- Method copy(notio.CopyingScheme, java.util.Hashtable)
- Currently uses CN_ copy flags. Should probably add referent flags.
- Method matchReferents(notio.Referent, notio.Referent, notio.MatchingScheme)
- Should add specified quantifier matching too.
- Should review descriptor matching to see if this is doing the right thing.
Class Comments
- What methods should parsers be forced to implement?
Class Comments
- This class is really superfluous unless we want special treatment for names which
should really just be relations.
Class Comments
- Escape sequences need work.
Method Comments
- Method escapeCharactersInString(java.lang.String, java.lang.String, char)
- Do we need to do some more work for stuff like newlines and tabs?
- Since the CGIF standard no longer escapes whitespace, we disable
the automatic whitespace escaping from this function. Should probably
finally remove this eventually.
Class Comments
- Doesn't handle 0-adic relations/actors.
- Doesn't actually generate Actors.
Method Comments
- Method generateGraph(notio.Graph)
- Currently divides into primary and secondary. Secondary could reduced to all
unrelated concepts, I think, since all related secondaries should be generated along
with a primary.
- Method generateConcept(notio.Concept)
- Defining label stuff is truly a gross hack.
- Should probably only generate linked relation if this
concept is the first argument (or last).
- Method generateRelation(notio.Relation)
- Assumes that first argument has already been generated.
- Method Actor(notio.Actor)
- Literal concept handling is just plain wrong.
Method Comments
- Method addCoreferenceSet(java.lang.String, notio.CoreferenceSet)
- Should this be setting "isDefiningEntry" to true or not?
Class Comments
- Currently catching ScannerError since token coverage is incomplete.
- Need to rework comments.
Class Comments
- Token coverage is probably inadequate. We sometimes throw TokenMgrError.
- ParserExceptions are still poor at providing locations. Need access to
scanner's state information.
- Graph termination problem remains. Can use at the end but doesn't
work for nested graphs. Should probably use to terminate Wrapper().
- Lots of ugly stuff in this class relates to outdated coreference scope checking.
- Ok: Need to pass several components down so we can connect them together when we
know they will really be used.
- What about the state of the defining label table after a ParserException?
Currently, the state should be assumed to be bad, so a new table or translation
context should be used in the future. Should we try to handle this elegantly?
Perhaps in CGIFParser.java?
Method Comments
- Method generateParserException(java.lang.String, notio.translators.Token)
- Should include the expected tokens.
- Method generateParserException(java.lang.String, notio.translators.Token, boolean, boolean)
- Should include the expected tokens.
- Method translateEscapeSequences(java.lang.String)
- Must add support for numeric escape sequences.
- Method NormalConcept(notio.translators.DefiningLabelTable)
- Some clarifying syntax removed to accomodate a bug in mparse 1.1. Does not
affect functionality.
- Needs serious cleansing.
- Method SpecialContext(notio.translators.DefiningLabelTable)
- Special context label is parsed but not used. It should probably be made
into a type if the appropriate expansion is not to be performed.
- Empty graphs?
- Method NegatedConcept(notio.translators.DefiningLabelTable)
- Empty graphs?
- Method MonadicLambdaExpression()
- Search concept type hierarchy for monadic before creating it? Currently
we just create an unlabelled type for every monadic we encounter.
- Very arbitrary hack used to find concept corresponding to formal
parameter. Only searches outermost context of differentia graph.
- Method DefinedLabel()
- Shouldn't this really be called a DefiningLabel?
- Method Referent(notio.translators.DefiningLabelTable)
- Certain quantifier/designator combinations don't make logical
sense but I don't think we can do anything about that here.
- Method EncodedLiteral()
- Need to invoke a decoder or create some dummy object. Probably need a flag
indicating whether dummy's should be used, perhaps with a maximum size parameter.
- Method Locator()
- No support for indexicals. Probably need a pluggable indexical handler.
- The treatment of a plain hash ("#") is probably not appropriate for
all situations. In any event, it certainly shouldn't be added to the
foreign ID translation table. That is included temporarily to facilitate the
Muto project's testing.
- Method IndividualMarker()
- We should do the individual marker handling here and return
a MarkerDesignator.
- Method ConceptComment()
- Must remove excess backslashes from final string.
- Method Relation(notio.translators.DefiningLabelTable)
- No valence checking. Probably should just be an exception thrown
by the Relation class. Actually, valence _is_ checked on construction.
Relation should probably be throwing something other than IllegalArgumentException.
- Method LambdaExpression()
- Need to fix some problems creating RelationTypeDefinitions
for an unlabelled RelationType.
- Do we really need to push a context here? Really don't need to pop it since
we just throw the table away.
- Method Arc(notio.translators.DefiningLabelTable)
- Need new way of determining context of arc concept. We'll use the
defining label tables.
- Method RelationComment()
- Must remove excess backslashes from final string.
- Method ActorComment()
- Must remove excess backslashes from final string.
- Method Name()
- Need to add support for unquoted names, if that ends up in the standard.
- Method Number()
- Currently all numbers are converted to doubles. Might want to be
more intelligent about this.
- Method UnsignedInteger()
- Currently all numbers are converted to doubles. Might want to be
more intelligent about this.
- Method processConceptDefiningLabel(notio.translators.Token, notio.Concept, notio.translators.DefiningLabelTable)
- What constitutes a legal redefinition? What happens if we
encounter a bound reference before a redefinition, within the same
context? Should definitions be accepted in a strictly left-to-right
manner or should they account for context?
Class Comments
- Should add 'useNegationAbbreviation' flag to generator.
Method Comments
- Method generateCGStream(java.util.Vector)
- Does not properly treat translation context.
- Method generateOutermostContext(notio.Graph)
- Does not properly treat translation context.
- Method Concept(notio.Concept, notio.translators.DefiningLabelTable)
- Perhaps we should assume a concept was parsed as a literal in a
relation if it has no coreference labels and not display it? Sounds
dangerous. Is there some way to do this intelligently so we don't risk
omitting it? What if it's not a member of a relationship?
- Removed exception thrown when there is a reference to a coref set that is not
in the table by a concept that has multiple sets. This whole coref thing needs to
be reconsidered in light of the idea that single concepts can be generated.
- Need to review colon generation conditions.
- Method Relation(notio.Relation, notio.translators.DefiningLabelTable)
- Literal concept handling is just plain wrong.
- Removed throwing of exceptions when there is no coref label since
just doesn't make sense if we want to print a single relation.
- Can relations not have a blank type field?
- Method RelationType(notio.RelationType)
- What about types with no label or definition? Anonymous types?
- What about types with both a label and a definition?
- Method Actor(notio.Actor, notio.translators.DefiningLabelTable)
- Literal concept handling is just plain wrong.
- Must be entirely reexamined and updated based on Relation() method.
(e.g. allowIncompleteRelation)
Class Comments
- Currently catching ScannerError since token coverage is incomplete.
Method Comments
- Method translateEscapeSequences(java.lang.String)
- Must add support for numeric escape sequences.
- Method Arc()
- We should probably throw an exception if an arc is numbered <= 0.
Class Comments
- This test is implementation specific since it relies on knowing which of the
redundant relations will be left after simplification and on the same instance being
returned by getRelations() every time it is called.
Class Comments
- Should add more structures to ensure adequate coverage.
Class Comments
- Need to add test cases for different constructors/uses of RelationTypeDefinition.
8 warnings