Java's DAO definition of Factory Method

I was reading today, again after many years, the article Core J2EE Patterns - Data Access Object and came across these two definitions of DAO implementations, the first one using Factory Method and the second one using Abstract Factory. Although the article claims the first example to be using factory method, I've started to think that it could just as well be defined as an abstract factory with a single concrete factory implementation.

Example Factory method:

Example Abstract Factory:

Going back to GoF, we can find arguments as to why it is an abstract factory:

• Abstract factory creates a factory of related products, which would be the single concrete implementation of the first example.
• Abstract factory is used, among other things, to create gui toolkit factories for different look and feels that would return different components to be worked on by other classes. These components are closely related. These would be the concrete dao factory implementation itself, which has methods for creating the individual products/daos.

I have also seen many discussions explaining the difference between inheritance (factory method) and composition (abstract factory) but I think that distinction is very ambiguous. In GoF we read that one of the two ways to use factory methods is to Connects parallel class hierarchies which means allowing classes other than the creator (class that implements the factory method) to call these factory methods.

If some class is calling a factory method from another class, using the interface exported by a creator, that is the same thing as calling a method from an abstract factory. Both examples use inheritance to benefit from the polymorfism and both are creating concrete produtcts, based on some abstract product interface. In essence, that means the same UML diagram could describe both patterns.

So in the end, I think it all comes down to whether I'm defining DAOFactory as a creator with multiple factory operations, in the case of factory method or an abstract factory in the case of an abstract factory, which have the following definitions in GoF:

factory method:

- constructor

* declares the factory method, which returns an object of type Product.
Creator may also define a default implementation of the factory
method that returns a default ConcreteProduct object.
* may call the factory method to create a Product object. 

abstract factory:

- abstract factory

declares an interface for operations that create abstract product
objects

So to decide whether the pattern is a factory method or an abstract factory, I need more than just the UML, but the requirement of the application to define what pattern best fits the description of the requirement. And so when I did that, it sounded like abstract factory fit better both examples from Oracle. First because all daos are tightly coupled. I could share the same connection between them right from inside DaoFactory of even share a transaction.

I don't think calling the first example factory method just because there was only one implementation is justification enough.

Have I missed something? Is my view of both patterns up to date or has it changed since GoF?