owl:FunctionalProperty and owl:InverseFunctionalProperty

[GoogleCodeExporter]

Topic or term(s) which needs clarification:
owl:FunctionalProperty and owl:InverseFunctionalProperty

Links to existing resources related to the topic:
List discussion starting at 
https://groups.google.com/d/msg/tdwg-rdf/h2Sq5nu7Ja8/sbRatmF0r6sJ

Wiki page to be used for guidelines:
UsageFunctionalProperty

Specific considerations to be addressed in guideline:
Under what circumstances is is justified to declare that a property is an 
owl:FunctionalProperty or owl:InverseFuctionalProperty?  What reasoning tasks 
does this impede?  What desirable inferences does this allow?

Original issue reported on code.google.com by steve.ba...@vanderbilt.edu on 22 Mar 2012 at 10:53

[GoogleCodeExporter]

Original comment by steve.ba...@vanderbilt.edu on 22 Mar 2012 at 10:55

• Changed state: Accepted
• Added labels: Reasoning

[GoogleCodeExporter]

In your June 9 posting in 
https://groups.google.com/d/msg/tdwg-rdf/h2Sq5nu7Ja8/sbRatmF0r6sJ you gave a 
correct statement of part of my objection to functional and inverse functional 
properties. 

You correctly read my mind in part. I do not like prematurely closing the world 
to no particular effect. However, one might argue that this is a design 
philosophy, and in early in the above discussion thread, Hilmar Lapp expresses 
the opposite philosophy.  All we can do is agree to disagree about that. 

BUT, there are far more serious consequences of your particular choices in 
darwin-sw, particularly, but perhaps not only, by your insistence on having 
inverse properties on things. More specifically, there is a penalty for having 
InverseFunctional properties (which, I believe are implied by having an inverse 
of a Functional property, whether you declare it or not).  InverseFunctional 
properties tend to interfere with tractability, and e.g., will always(?) admit 
of reasoning instances that will never terminate, or, only mildly better, are 
exponential in the size of the resources. The present darwin-sw, even when some 
probably inadvertent issues are corrected, is not OWL DL, (hence the 
intractability) largely(?) because of the InverseFunctional properties.  You 
can see this with the WonderWeb validator 
http://www.mygrid.org.uk/OWL/Validator after you fix a few incorrect xml entity 
references in the current darwin-sw that, for which I have opened an issue in 
the darwin-sw google code project.  (It's important to note that 
InverseFunctional properties are actually needed to model relational databases, 
and OWL2 has a tractable way around this with "keys".)

My position is roughly that you are enforcing your opinion of a best practice 
to no great advantage and sometimes to disadvantage, when combined with other 
modeling choices you are making on the same grounds, e.g. having inverse 
properties.  In my opinion, you should ask yourself what is the cost of not 
having, e.g., inverses and functional, and inverseFunctional properties, 
compared to the cost of having them.  Consider your example of  'atEvent' with 
those restrictions omitted. What's the cost of there being data in which an 
Occurrence has more than one Event. My answer is very little, because it is 
always possible to use SPARQL filters to ignore the data that don't meet this 
particular "best practice". (For an example, see a related issue in the section 
"Rules, Filters, and Validation", pp. 18-20 in [1].)

[1]R. Morris, L. Dou, J. Hanken, et al. "Semantic Annotation of Mutable Data", 
under submission. Manuscript at 
https://sourceforge.net/projects/filteredpush/files/SemAnnMutableDataV0994/

Original comment by morris.bob on 10 Jun 2012 at 11:30

[GoogleCodeExporter]

Thank you for your comments and for looking carefully at darwin-sw.  I'm a bit 
puzzled about it not validating as OWL DL because we did get it to validate as 
DL when we posted the last version, although that has now been months ago and I 
no longer remember the details.  Nevertheless, your point about Functional and 
InverseFunctional properties is well taken.  We had not put this level of 
thought into the implications of assigning those properties, but rather 
included them because we thought they modeled the relationships as we saw them. 
 So it might be going too far to say that it was part of a design philosophy 
and it might be better if we took them out.  

However, if the Functional/InverseFunctional properties were not there, what 
problems would there be with declaring pairs of them to be inverse?  It would 
result in a machine inferring a triple stating the inverse relationship (i.e. A 
dsw:atEvent B implies B dsw:eventOf A), but that is actually exactly what we 
want to happen.  In the example I gave at 
http://bioimages.vanderbilt.edu/baskauf/11713.rdf I declare dsw:atEvent and 
dsw:locatedAt relationships, but if those triples were loaded in a store, I 
would like for the manager of the triplestore to be able to infer the inverse 
relationships that I did not state explicitly.  For example, as that RDF 
currently stands, a query asking what events occurred at that location using

<http://bioimages.vanderbilt.edu/baskauf/11713#loc> dsw:locates ?

would not pick up the relationship between 
http://bioimages.vanderbilt.edu/baskauf/11713#loc and 
http://bioimages.vanderbilt.edu/baskauf/11713#eve as it is currently described 
using dsw:locatedAt without the two properties dsw:locatedAt and dsw:locates 
being declared as inverse properties.  

I suppose that an alternative would be to simply provide only one object 
property to connect each class rather than pairs of inverse properties and that 
would force people to write the triples in only one direction.  But that would 
impose more constraints on how people had to write their RDF.  It seems to me 
that it would be better to impose the burden on the data consumers (i.e. to 
infer the inverse relationships) rather than to impose the burden on the data 
providers (i.e. to express the relationships in only one way) because it seems 
more likely that the data consumers are generally going to be more savvy in 
doing their jobs than the providers.  Besides, the data consumers are going to 
have to do a lot of other processing tasks to clean up the data anyway.  

Original comment by steve.ba...@vanderbilt.edu on 11 Jun 2012 at 12:33

[GoogleCodeExporter]

As I suggested on the mailing list, with respect to "occurrence at event". I 
suggested that there be a functional property "atEvent", whose meaning is "the 
finest, most atomic event at which the occurrence occurred", and an "inEvent".

The functional property "atEvent" would be a subproperty of the nonexclusive 
"inEvent".

This pattern applies in many places - atLocation / inLocation (or 
inGeographicArea), atTime/inDateRange and so on.

I also suggested that the property chain (inEvent, partOf) be declared a 
subproperty of inEvent, but this would only apply to a specific "partOf" 
predicate that means event being a sub event of another event (as opposed to 
event "part of" somebody's research effort, which is a slightly different 
thing).

The "event:partOf" relationship could also be broken up in this way: into a 
transitive, reflexive "partOfEvent" and a functional "atEvent", where atEvent 
is a subproperty of partOfEvent (possibly there is a better choice of names for 
these predicates). "partOf" permits reasoning, "atEvent" allows construction of 
a hierarchical list.

Finally, although a rule *could* be included to the effect that if an 
occurrence is AT eventA and IN eventB, then eventA must be partOf event B, this 
will quite thoroughly break OWL DL tractability. 

Original comment by pmurray....@gmail.com on 13 Jun 2012 at 1:50

[GoogleCodeExporter]

Apology and partial retraction of 
http://code.google.com/p/tdwg-rdf/issues/detail?id=11#c2 

Ah, darwin-sw v. 0.2.1 is indeed OWL DL, and does indeed is declared such by 
the Manchester Validator. My error is that InverseFunctional is forbidden in DL 
only for Data  properties, not for Object properties, which is all that you 
apply it to. Thus my objection on tractability grounds is wrong, and I retract 
all of the paragraph beginning with "BUT". I still hold to the position that a 
less restrictive ontology, perhaps with best practices implemented in rule 
languages, is more useful than an ontology that enforces those practices.

Separately, I think that in general should also consider which of the OWL2 
standard profiles an ontology fits (See 
http://owl.cs.manchester.ac.uk/validator/) and inquire whether there is a case 
for each. See especially http://www.w3.org/2007/OWL/wiki/Profiles. For example, 
OWL2 EL is said to be especially useful when there is a large number of classes 
and/or properties. This might apply to those who wish to model every species as 
a class, as has recently come up in the discussion list.

Original comment by morris.bob on 13 Jun 2012 at 3:47