The Web Graph Database

wiki:Docs/FAQ

InfoGrid Frequently Asked Questions (FAQ)

Questions related to information instantiation and management

What's the largest possible graph one can instantiate using InfoGrid?

The size of the MeshObjectGraph is only limited by external storage capacity as the StoreMeshBase dynamically swaps in and out the MeshObjects in the graph as they are used by the application. Of course, the more swapping, the slower the application.

Does InfoGrid perform any sort of domain checking when assigning PropertyValues?

Yes, InfoGrid checks all PropertyValues prior to performing any assignment. This means, among other things, that you can’t assign a negative integer number to a Property whose PropertyType specifies that it can hold positive integers only (by virtue of referencing a DataType in the Model that captures that). Similarly, you cannot assign an enumerated value from one domain (as defined in the corresponding EnumeratedDataType) to a Property using a different EnumeratedDataType; that even applies to enumerated values that are represented as the same string. Some of the potential erroneous assignments are found at compile time, and all others will cause a run-time Exception to be thrown.

What happens if I assign null to a Property whose PropertyType does not specify <isoptional/>?

You can’t. If you try, InfoGrid will throw an exception.

What happens if I attempt to instantiate an EntityType or RelationshipType that's declared as abstract?

In general, you can’t. If you try, InfoGrid will throw an exception. (But see: ForwardReference)

Why do you require the use of your own value types for Properties, e.g StringValue, instead of using the language’s own data types?

This is partially addressed by the answer to the previous question about why we limit the set of allowed data types for PropertyTypes. Further, we also wanted to provide methods such as PropertyValue getPropertyValue( PropertyType ma ); which requires us to have a common supertype over all possible return types. In order to catch as many programming errors at compile time as we could, we wanted to avoid that this be java.lang.Object or similar.

Questions about import and export

How can one get data into or out of InfoGrid applications?

See this blog post.

Questions related to modeling

Why did you define your own modeling language in InfoGrid, instead of using XML Schema, UML, XMI, RDF, RDF Schema, OWL, STEP/EXPRESS ..?

There are two answers to this question:

  • It is unclear which of the above list of standards (none of which is suitably integrated / merged with any of the others, by the way) would be the most appropriate to choose. Some people would argue it is the Unified Modeling Language (UML) and its transfer format XMI as standardized by the Object Management Group. Others would argue that it should be some version of XML, such as XML Schema, RDF or RDF Schema, or OWL. As long as so many choices exist, and there is no industry consensus on where to apply which, it is not clear which of the above InfoGrid should adopt, if any. Also, most of the above standards are too generic for the purposes of InfoGrid, which would require us to define a more concise "profile" suitable with use of InfoGrid. (In a way, that is what it turned out to be.)
  • InfoGrid has some unique requirements with respect to information modeling that either cannot be met, or are at least difficult to meet with other information modeling techniques. Some examples are: the ability to have RelationshipType inheritance (a feature that has turned out to be highly important for some InfoGrid applications), the ability to override PropertyType definitions in subtypes, or the ability to define the algorithm for calculating the value of a ProjectedProperty right in the model.

Why do you provide only a limited set of DataTypes for PropertyTypes, instead of supporting arbitrary Java classes?

  • In case of a multi-Node deployment, values of Properties must be sent across the wire, using the XML-based XPRISO protocol. As it is generally not possible to predict the implementation environment of other Nodes, it is impossible to use programming-language specific concepts (such as “arbitrary data types in language X”). Instead, it is necessary to enumerate, and list, all possible data types for Properties whose values may be sent across the wire as part of the interface definition between the nodes.
  • For the same reason, we cannot use a general-purpose serialization mechanism such as Java Object Serialization: that would limit InfoGrid Nodes to be implemented in Java, or even in a particular version of Java.
  • There is another reason: In InfoGrid, information is structured by instantiating and relating MeshObjects, which may be blessed with EntityTypes and RelationshipTypes respectively; using non-primitive Properties defeats that approach. The only exception is the BlobDataType, which is (weakly) structured through its MIME type and can hold arbitrary serialized data.

Why do you use the term "meta" so often?

We don't. Just look at InfoGrid 2.x. What made you ask that question? ;-)

Questions related to XPRISO

Is there a separate document describing XPRISO?

Not currently. There is some documentation in the code; if you like to volunteer and put up a page on this wiki, please do so.

Where is XPRISO used in InfoGrid at this point in time?

For the Probe Framework, which allows developers to treat data sources external to InfoGrid (e.g. RSS/Atom feeds, web services, screen scraping...) as object graphs that become seamless subgraphs of the application's object graph. The current implementation is in-memory only.

Why isn't there an XPRISO implementation that works over the network?

There used to be, using CORBA, Java RMI and even Project JXTA. For a variety of reasons that code fell out at some point; a new implementation is needed. It's fairly straightforward to do given that there is a working in-memory implementation, but we haven't gotten around to it. Volunteers? ;-)

Last modified 4 years ago Last modified on 05/10/10 04:37:17