Skip to content
This repository has been archived by the owner on Jun 15, 2018. It is now read-only.

Properties with too specific domains? #24

Open
GoogleCodeExporter opened this issue Mar 13, 2015 · 6 comments
Open

Properties with too specific domains? #24

GoogleCodeExporter opened this issue Mar 13, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

Description of the issue or change request

This has been discussed in past occasions.

From 2010-08-10's telecon

    *  Properties with too specific domains!  Do not specify domain unless there is a good reason.
    * Maintenance and re-use problem.
    * In some cases the domain is the union of other classes, eg., hasPointOfContact’s domain is the union System + Manufacturer
    * OWL 2 annotations may be used to better address this issue.
    * Also look at OWL 2 profiles (one or more restrictions)
          o important to us?
          o nailed down domains good or bad? 
    * Which property restrictions are more for documenting than for reasoning?


Please provide any relevant information/links below

- http://marinemetadata.org/community/teams/ont/property-modeling

- Chat room messages at: 
http://marinemetadata.org/community/teams/ontdevices/agendas/minutes20090623




Original issue reported on code.google.com by [email protected] on 10 Aug 2010 at 4:15

@GoogleCodeExporter
Copy link
Author

Bob: just adding here a couple of points we mentioned today and that I just put 
in the minutes:

# An immediate benefit of the current approach is that we are very clear (at 
least by looking at the ontology diagram) about the main use we want for the 
properties. For example, we are at this point only interested in being able to 
say that Systems and Manufacturers have points of contact.

# If we leave hasPointOfContact without any explicit domain (ie., with implicit 
domain rdfs:Resource==anything), how can we emphasize the actual use we are 
mostly interested in?

# As said in a previous meeting, the current approach does not prevent us from 
introducing the most general properties later on and making the current 
properties subproperties of the relevant ones (perhaps with some appropriate 
renamings).

Original comment by [email protected] on 10 Aug 2010 at 4:28

@GoogleCodeExporter
Copy link
Author

To summarise my current position on the points


# If we leave hasPointOfContact without any explicit domain (ie., with implicit 
domain rdfs:Resource==anything), how can we emphasize the actual use we are 
mostly interested in?

# An immediate benefit of the current approach is that we are very clear (at 
least by looking at the ontology diagram) about the main use we want for the 
properties. For example, we are at this point only interested in being able to 
say that Systems and Manufacturers have points of contact.

My thought on these twp is that it may be a (probably very minor) feature lack 
in the diagram generator.  My suspicion is that OWL2's more extensive handling 
of annotations can probably be used to accomplish the same thing, and probably 
with minor reuse of the diagram generation code.  I commit to looking into the 
OWL2 spec to see if my suspicion has merit. Carlos should also poke around in 
OWL2. Maybe we start in 
http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2010_07_29#nid2FYS 


# As said in a previous meeting, the current approach does not prevent us from 
introducing the most general properties later on and making the current 
properties subproperties of the relevant ones (perhaps with some appropriate 
renamings).

True, but it introduces a potential maintenance burden. It has to be done with 
all properties to which this (undocumented?) policy applies.  Even if such a 
mechanism is desired, my above OWL2 suspicions suggest that the OWL2 annotation 
mechanisms would allow a simple OWL2 annotation assertions to be written for 
which an annotation reasoner would signal neglect to update Domains. On the 
other hand, that may be needlessly complex if the real issue is mainly to help 
developers know what is "expected" rather than required.  BUT:

My bigger worry is that setting the Domain on a property might make it 
difficult or impossible for two devont extensions to be simultaneously 
consistent.
I commit to trying to make a simple example of this.





Original comment by morris.bob on 10 Aug 2010 at 6:48

@GoogleCodeExporter
Copy link
Author

One more related MMI page: 
http://marinemetadata.org/community/teams/ontdevices/ontbasicsproperties

Original comment by [email protected] on 10 Aug 2010 at 11:35

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

've had occasion to look at the OWL2 Annotation Property support. Any 
rdf:Property can be declared to be an owl2:AnnotationProperty, and although not 
here necessary, you can reason on owl2:AnnotationProperties independently of 
the regular properties in the ontology. (For example, (I believe) you can ask 
SPARQL queries about AnnotationProperties that behave as expected through a 
SubAnnotationProperty hierarchy.).

A small specific set of standard rdf:Property's are predefined as being 
owl2:AnnotationProperty. But none seem suitable for this purpose. See 
http://www.w3.org/TR/owl2-syntax/#Annotation_Properties

Something like this snippet of OWL2 in Manchester syntax might work:

AnnotationProperty: designTarget
 AnnotationPropertyRange: xsd:anyURI

ObjectProperty: hasPointOfContact
  Annotations:
      designTarget : <http://URI_For_UnionOfSystemAndManufacturer>
  ...

Individual: <http://carlos.org/Systems/s1>
 Types:
    <http:mmi.org/uriForSystemClass>

 Facts:
    <http://mmi.org/devont#hasPointOfContact> <http://morris_systems.com/contacts#Bob>
    <http://mmi.org/devont#someStringAttribute> "theValue"
....

Original comment by morris.bob on 21 Sep 2010 at 4:52

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant