Re: [Fenfire-dev] RDF traversal utility methods

[Tuomas Lukka]

On Sun, Aug 17, 2003 at 06:19:31PM +0300, Tuukka Hastrup wrote:
> 
> This is getting complicated, isn't it? And adding to this, getComponents
> should also tell which of the components was with most nodes. Asko would
> like the Set sorted by the component size, I would like to return new
> Object[2] {components, largest}. I could return an iterator that gives the
> largest first.

Since you're going through all anyway, why not return number of nodes
in each component at the same time? That's practically *free* info.

> Should we also consider Java<->Jython interfacing? I didn't find easy ways 
> to transfer iterators, sets or sequences between them.

Sequences are automatically mapped by jython, I think.

For others, a utility somewhere might be good.

> On Sun, 17 Aug 2003, Tuomas Lukka wrote:
> > On Sun, Aug 17, 2003 at 04:17:38PM +0300, Tuukka Hastrup wrote:
> > > On Sun, 17 Aug 2003, Tuomas Lukka wrote:
> > > > Actually, for this purpose, how about 
> > > > 
> > > >         swamp.util.Iteration.iterateAllNodes(ConstGraph g)
> > > > 
> > > > for getting all nodes?
> > > 
> > > Wouldn't it make sense to have it in ConstGraph interface? And it could
> > > have iterateAllSubjects and iterateAllObjects as well, and iterateAllNodes
> > > would just combine them.
> > 
> > No, that's not true - there are also predicates.
> 
> I didn't think of those, wouldn't that be more like iterateAllURIs? 

No. All *nodes*. 

Predicates are nodes, too.

> Would
> you say they're nodes if they are neither subjects nor objects? 

Yes.

> > And we want each node only once.
> 
> This I didn't think of neither :-( But you can do filtering while you go 
> 8-)

I think your "convenience" routines should take care of this ;)

> > > > So I'm thinking: to do better in that way, we should maybe have
> > > > findN_AAX_Set which returns a set of nodes.
> > > 
> > > Do you mean for all findN methods, or these as a special case?
> > 
> > All.
> 
> At least for HashGraph it would make sense. And implementation looks 
> trivial: just remove the iterator() method calls on HashSets.

But of course I'd at the end of the day like the set to be backed 
by the structure for removals and insertions...

> > > > However, efficiency may be a problem there :(
> 
> What do you have in mind, then?

Not sure. Well, it wouldn't make the other calls less efficient so I guess
it's ok.

> > > In addition to general overhead, at least concatenating two iterators is 
> > > simple, but set union I'd imagine is not.
> > 
> > Both are O(N).
> 
> Hmm, at least a new iterator can be created in O(1), and it can be backed 
> up by the two iterators. You could look at Traversals to see what I mean.

Yes, but it still takes O(N) extra time when iterating for bookkeeping.
Each next() and hasNext() call does that.

        Tuomas