A second set of issues is that methods like model.getBag() return resources that do not return true for the isX() methods if the resource was not already in the model.
Bag b = model.getBag( "foo") expect b.isBag() == true but get b.isBag() == false This also applies to getAlt() and getSeq(). This does not apply if the resource exists in the graph (e.g. createBag() was called) I suspect that the problem is that the statement <foo, RDF.type, RDF.Bag> is not in the model so isBag() returns false. I don't know how to fix this other than to make getBag() and createBag() the same method. As a side note. The only way I can find to tell that the bag is not in the graph is to call getBag() and then check that the isBag() method returns false. I also note that calling bag.add(false) does not add the <bag, RDF.type, RDF.Bag> to the model. On Sat, Sep 21, 2013 at 3:42 PM, Claude Warren <[email protected]> wrote: > After a bit more work.... I have the following > > Resource r = resource of model 1 ( a memory model) > Model m2 = model 2 (an empty defaultModel) > > Bag bag = m2.getBag( r ); > > bag.getModel() returns model 1 > > Looks like getAlt(), getSeq() and getResource() seem to act the same way. > > I suspect that those implementations should call inModel() to ensure that > the model is correct. > > Digression: > > Is this the right time to split the Model-API (APIs?) from the core > graph-level machinery into a separate module? (I don't understand this > question). Are you saying you would like to see all the interfaces and > helper classes in a module and the memory implementation in another? Do we > want to do this? If not, what do you mean? > > Claude > > > > On Sat, Sep 21, 2013 at 2:51 PM, Andy Seaborne <[email protected]> wrote: > >> On 21/09/13 10:08, Claude Warren wrote: >> >>> There are several methods listed in the Model and ModelCon interfaces >>> that >>> return the model for chaining purposes. >>> >>> I want to test that the model is returned. >>> >>> Assuming the a method call: >>> >>> Model m = // create a model >>> Model m2 = m.f(x) >>> >>> I believe the requirement is for >>> m2 == m to be true >>> >> >> Same here - if the contract is also: >> >> m.f1() ; >> m.f2() ; >> m.f3() ; >> >> has the same effect as m.f1().f2().f3() then i don't see theer is mouch >> choice other than m2==m. >> >> >> >>> A similar requirement is for items created on the model be "of" the model >>> (not necessarily in the model). For example ModelCon.createStatement( >>> Resource, Property, String ) should return a statement such that >>> >>> Model m = // create model >>> Statement s = m.createStatement( Resource, Property, String ) >>> should return a statement such that the statement is not in the model >>> (m.contains(s) == false) but is of the model (s.getModel() == m) >>> >>> The question is should the second test be s.getModel() == m or >>> s.getModel().equals(m)? >>> >> >> Isn't Model.equals same as == anyway? As model can be large, it seems to >> me there isn't much choice from a practicality standpoint. >> >> >> There is one case getAlt() >>> Model m = // create model; >>> Alt a = m.getAlt( Resource ); >>> >>> where both a.getModel() == m and a.getMode().equals(m) are false. >>> However >>> a.getModel.isIsomorphicWith( m ) is true. >>> >>> I believe that in both cases the correct tests should be >>> m2 == m >>> and >>> x.getModel() == m >>> >>> Comments? >>> >> >> Weird - where in the code base is a different model being created? >> >> And is method-chaining broken? >> >> m.getAlt(...).add(...) >> vs >> m.getAlt(...) >> m.add(...) >> >> >>> Claude >>> >>> >> Digression: >> >> Is this the right time to split the Model-API (APIs?) from the core >> graph-level machinery into a separate module? >> >> Andy >> >> > > > -- > I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
