Why does one need a blank node to define an equivalent class in OWL? Wouldn't the following two be equal?
:Wine owl:equivalentClass [
a owl:Class ;
owl:unionOf (:RedWine :RoséWine :WhiteWine) ] .
and
:Wine a owl:Class .
:Wine owl:unionOf (:RedWine :RoséWine :WhiteWine) .
This isn't quite a duplicate of Why use owl:Restriction as own:EquivalenceClass's property?, but the answer is roughly the same: the mapping from RDF to OWL is defined in a such a way that this abbrevation wouldn't produce the ontology you want when you map the RDF to OWL. Whether or not you'd end up with ambiguity or not, I'm not sure. However, you won't end up with the ontology that you want. The relevant translation from RDF to OWL says that when you have:
_:x rdf:type owl:Class .
_:x owl:unionOf T(SEQ y1 ... yn) .
{ n ≥ 2 and CE(yi) ≠ ε for each 1 ≤ i ≤ n }
you get a class expression, ObjectUnionOf(CE(y1) … CE(yn)). According to 3.2.4 Parsing of Expressions, expressions are parsed first, and then axioms are parsed next. Importantly, "Each time a pattern is matched, the matched triples are removed from G." That means that we parse the expression the RDF:
:Wine rdf:type owl:Class .
:Wine owl:unionOf (:RedWine :RoséWine :WhiteWine) .
we get the class expression, RedWine ∪ RoseWine ∪ WhiteWine, and we remove the triples from the graph. Later on, in 3.2.5 Parsing of Axioms, we'd start to look for instances of ?x rdf:type owl:Class in order to get the declaration axiom Declaration(Class(?x)). However, we removed the triple :Wine rdf:type owl:Class when we parsed the unionOf expression. Now we don't have Wine as a class in the ontology.
Now, the reason that the abbreviation doesn't work is because the translation doesn't support it. The translation removes triples from the graph when it encounters them, and it removes expressions first, which would then leave the necessary triples unavailable for the declaration axioms. However, we could imagine a translation axiom that didn't remove them; it might just parse expressions first, and then parse axioms later. I think the abbreviation that you're describing would be that
:A owl:equivalentClass :B .
:B ?p ?o .
can be replaced with:
:A ?p ?o .
as long as it's done for all the ?p ?o that :B has. This might not be a problem for unionOf expressions, since each unionOf expression requires a single ?p ?o (where ?p is owl:unionOf and ?o is an RDF list). However, for any class expression that requires more than one triple has the possibility to become ambiguous, if there's more than one equivalent class expression of the same type. E.g., if you have the triples
_:x rdf:type owl:Restriction .
_:x owl:onProperty y .
_:x owl:someValuesFrom z .
to specify a someValuesFrom restriction, then as soon as you have two of them, you don't have a way to know which owl:onProperty goes with which owl:someValuesFrom. That's the issue that came up in Why use owl:Restriction as own:EquivalenceClass's property? If owl:unionOf was encoded a bit differently, the same issue would come up. E.g., if A ∪ B was encoded by:
_:x rdf:type owl:Class .
_:x owl:unionMember :A .
_:x owl:unionMember :B .
then you'd run into ambiguity if you tried to encode the axioms:
A ≡ B ∪ C
A ≡ D ∪ E
You'd get the encoding:
:A rdf:type owl:Class .
:A owl:unionMember :B .
:A owl:unionMember :C .
:A owl:unionMember :D .
:A owl:unionMember :E .
which you might read back as:
A ≡ B ∪ C ∪ D ∪ E
which is not logically equivalent.