It depends on whether Web Ontology Language (OWL) methods should be applied to Bibframe for resolution of works and instances, or if ISBN identifiers should be moved away from the Bibframe scope to get handled in programming languages.
The challenge with option 1) is that ISBNs must conform to the RDF rule that there must be a lexical space, a value space, and a lexical-to-value mapping. In my bibliographic applications I store each ISBN three times: an original form (the lexical value from a catalog source, including incorrect ISBNs), a value form (without hyphens and correct checksum and each ISBN-10 mapped to ISBN-13), and the alternative value (ISBN-10, if existing, with the ISBN-10 checksum, for matching all kinds of ISBN queries). This shows there is a normal form of an ISBN, but it can be augmented with variants which are also valid, which adds some complexity to parse and represent ISBNs like we programmers do with datatypes in programming languages. It is possible to implement, but not easy to explain to the hasty programmers or sceptical users out there.
Option 2) is useful for resolving inverse functional properties in OWL, that is, if there is a property bf:isbn with the same literals asserted to two different subjects, the assumption can hold that the two subjects are equal under the presumption only one bf:isbn property can be asserted. This reminds me of the bf:Instance discussion that bf:isbn might identify a bf:Instance. Such ISBN literals can be arbitrary strings. It does not matter if they are ISBN-10, ISBN-13, with or without hyphens, correct or incorrect variants. It should not be expected that OWL resolution can normalize all forms of an ISBN intrinsically. The normalization would be an extra step in the preparation of Bibframe data, like we are used to it in the world of MARC today.