Only the OWL Full version of OWL allows an IFP to take literal values; in DL and Lite each IFP is an ObjectProperty (@@refs).

Here is a quick set of examples for discussion, exploring how this affects resource description in OWL.
This discussion highlights some interactions between technical features of RDF/RDFS/OWL, as well as the relationship of those issues to the expressiveness, power and utility of the various OWL profiles (Full/DL/Lite). This may help illustrate the design choices faced by (a) vocab creators ("should I use an ObjectProperty here?") and (b) data consumers ("What conclusions can I draw here?").

In OWL, there are two kinds of properties. Each property is either a DatatypeProperty or an ObjectProperty. ObjectProperty: values are always resources (represented in RDF either as bNodes or with a URI name). DatatypeProperty: string-valued, optionally with datatype info, xml language tagging etc. In OWL DL and OWL Lite, these are distinct. This breaks with deployed practice for some RDF vocabularies (eg. Dublin Core's dc:creator property). OWL Full allows such scruffyness to continue.

In OWL DL (and OWL Lite) you can't use textual IFPs. This is because in OWL, an inverse functional property is just that, the inverse of a functional property. However, datatype properties (such as eg:age) can't have inverses, due to RDF's restriction that the subject of each RDF statement much be a resource, never a literal. The Description Logic semantics of OWL DL exploit this when formalising the meaning of IP and IFP, which is why they exclude the (otherwise seemingly reasonable) possibility of inverse functional properties taking string values.

Here we try using one of these to description homepage of a company. In this example,
there are two very slightly different URIs denoting the same document, so we will
need a little more help to draw the conclusion that these descriptions can be merged.

Scenario 1: We are using a resource-valued IFP (ie. ObjectProperty) to individuate companies.
Note that here, the use of homepage as an identification strategy
breaks down. We have two company descriptions, the first of which
relates a company to the resource with URI http://testcorp.example.com/
and the second to the resource with URI http://testcorp.example.com:80/
Only later do we learn that these two URIs denote the same resource.

Scenario 2: a loosly situation, but here we have two company descriptions with
fc:nasdaqCode properties that have the same value. Unlike with the URI-based scenario, here we know immediately whether the company-descriptions are descriptions of the same company or not. This also puts us in the OWL Full
profile of OWL. Note that the situation isn't entirely the same, since we make use of the fact that this
fc:nasdaqCode property happens also to be a FunctionalProperty. We can't/don't assume the same of foaf:homepage (since multiple documents can be the homepage of the same entity).

Scenario 3: what if the descriptions were actually of different companies? How would we know?
This is where the difference really hits us...

OK here I should explain a potential confusion/complication. The RDF/OWL vocabulary we're using declares
foaf:homepage as an inverse functional property, as well as fc:nasdaqCode as an inverseFunctionalProperty. That means that there is at most one thing that has any given value for said property. We also, please notice, declare fc:nasdaqCode to be a functionalProperty: there is at most one value for that property for any thing. We don't do this for homepage, which breaks the symmetry and prettyness of the argument sketched here.

Here we can, using OWL Full, conclude that there are two distinct companies being
described here. Since the fc:nasdaqCode values differ, we know that these couldn't be true descriptions
of a single company. OWL DL/Lite could conclude that. But OWL DL/Lite would have trouble with the
case where the values were the same, since it doesn't acknowledge that text-valued properties can be uniquely
identifying. Note that this differs from the situation with URI-valued properties, due to
the absence of a unique names assumption in RDF. We can see that by considering a
similar example, in which two companies are described solely with reference to their
homepages.

Now is this enough to allow us to know for sure that two companies are described here?
Unfortunately not (regardless of OWL Full vs DL vs Lite). The problem is that this situation
is, for machines, indistinguishable from scenario 1 (ie. a.rdf through b.rdf) shown above, in which two
different URIs are deployed for the selfsame resource. The machine has no way to tell that
http://betacorp.example.com/ and http://zetacorp.example.com/ denote different resources, unless we
tell it. They could (like http://testcorp.example.com:80/ and http://testcorp.example.com/) simply be
two names for the same thing. With a literal-valued property (such as fc:nasdaqCode) this doesn't arise,
since different textual values immediately tell us the resources they're attached to are distinct individuals.

Hmmm: (arguing with myself here) this is a bad argument, needs fixing. the point is well motiviated, ie. that the lack of unique name assumption in RDF/OWL interacts with the utility of the semantics of FP and IFP. But even if these were string valued properties, we'd need to have declared foaf:homepage as a functional property to conclude distinctness on basis of distinct values for that property. @@fixme

However, with literal-valued properties it is not possible to state that two individuals with different values are actually one individual, since literals cannot be the subject of an RDF statement, and thus owl:sameAs cannot be used.

This example (@@correct if wrong please!) outlines one reason why RDF datasets and vocabularies might want to
draw upon the facilities of OWL Full, as well as suggesting a family of test cases for OWL DL/Lite reasoners. We should be
able to check that DL-based systems don't draw conclusions that are unwarrented by the data. (One approach here might be for
these systems to have a 'make unique names assumption' facility available explicitly within API or query interfaces?).