Stats Method on metadata store providing different numbers accross implementations

[GoogleCodeExporter]

Running into an issue where statistics for counts of OVAL def criterion 
references is not the same between triple store and memory store.  The triple 
store is consistently reporting less 
"urn:scap-content:relationship:org.mitre.oval:criterion" relationships than the 
memory store.

It took me a while, but i've finally tracked this down to an issue being caused 
when persisting an OVAL definition that has duplicate criterion references.  
They are not strictly duplicate because they appear under distinct logical 
operators.  For example, oval definition oval:com.redhat.rhsa:def:20080937 in 
the redhat xml lists two criterion that both reference test 
"oval:com.redhat.rhsa:tst:20040449005"; this is valid because the two criterion 
appear under two distinct criteria operators in the definition. 

The problem comes about from the fact that our meta-model does not go down to 
this level of detail; all I see coming in is an OVAL definition Entity with two 
KeyedRelationships with the same type/ID, and both pointing to the same test.  
By default the sesame API does not allow duplicate statements to be added into 
the repository and I am not sure if there is a way around this.

I will search for it, but do you think this causes any issues relating to 
document re-constitution? 

Original issue reported on code.google.com by Paul.Cic...@gmail.com on 20 Mar 2011 at 7:05

[GoogleCodeExporter]

After giving this some more thought I do not actually think it will be useful 
to add in the duplicate statement/relationship.  We are going to have to give 
this some more thought, I think either we want to update the metamodel to 
clarify this ambiguity  or we leave it alone.....from the point of view of pure 
relationships between atomic entities there really is only one relationship, 
just repeated multiple times from different contexts.  In any case we can deal 
with it after the demo, we just need to be aware that the memory store and the 
triple store give different numbers for the criterion relationships right now.

This is the TODO: i put in the class:

NOTE: there is an issue in some cases where an Entity will be sent
     * in containing duplicate relationships. At present only the first of the
     * set of duplicates is added; from the context of the triple store this is
     * the only useful behavior. The duplicate relationships make sense within
     * the context of a larger XML document, but the abstraction of the
     * metamodel removes that context, and therefore removes the usefulness of
     * the duplicate relationships. An example of this is the
     * "urn:scap-content:relationship:org.mitre.oval:criterion" Keyed
     * relationship in an Oval definition. An oval def. may have multiple
     * criterion relationships that are all equal (i.e. reference same test)
     * except for the fact that they appear under distinct criteria operators;
     * since the metamodel does not capture this extra context the relationships
     * just appear to be exactly the same.  WE NEED TO FIGURE OUT HOW TO HANDLE THIS.

Original comment by Paul.Cic...@gmail.com on 20 Mar 2011 at 7:05

[GoogleCodeExporter]

Just updating based on in-person discussion.  Decision was to change 
memoryStore implementation to match what the triple store is doing.  The 
reasoning here is that when you only have the context provided by the current 
metamodel the relationships are just purely duplicate.  The extra context 
provided by the OVAL criteria operators is removed at this level so we don't 
need to capture it.

For what we are doing this is fine; we just need to know that there is a 
relationship between the OVAL def and the state, and similarly for any generic 
instance of this case.

Original comment by Paul.Cic...@gmail.com on 20 Mar 2011 at 7:08