Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] FW: More changes to higgins.owl (in v1.10)

In the OWL Guide, Section 1 (Introduction) talks about "facts not literally present in the ontology, but entailed  by the semantics.  Section 2.3 (Data Aggregation and Privacy) talks about this fact and uses the word "inferences".  Basically, the ability to "reason" is described throughout this document as being one of the purposes of OWL.  So, to answer your question directly and technically, I'd say; yes, however "inferences" is also correct for referring to any "facts entailed by the OWL semantics".

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/20/2006 6:37 PM >>>
yeah, this kind of thing is needed in a few areas. Let me see if I can enumerate them all:
 
Type Hierarchies in search filters
- Digital Subject types (Tom's example)
- Attribute types (parentOf may be a subtype of SubjectRelationship)
- Metadata types (on digital subjects as well as on attributes)
 
Selection statements (this is not yet available, but needs to be: the ability to ask for specific types of attributes to be returned. e.g. "return only attributes which are of type SubjectRelationship" or same as that but "and also subtypes of that".
 
Related to above, there's a proposal to pass a type selection specifier for these: IHasAttributes.getAttrbutes(), IHasMetadata.getMetadataSet(), IHasProperties.getProperties().
 
Attribute types in IContext.verifySubjectAttributes(). Actually, we may want to revisit this method to make sure it does what we really want.
 
Not that I think it matters much, but in case it leaks into a method name, is the term "inferences" correct for referring to the relationships between super/sub types?
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 10/20/06 10:07 AM >>>
I think we also need a comparator that will apply to OWL inferences.  For example, in our LDAP ontology, a Digital Subject may be an "organizationalPerson" which is a subclass of "person".  A plain EQ comparator for Digital Subjects that are "person" I assume would fail any "organizationalPerson" without a comparator that allows inferences to be considered as well.  I think both semantics are desirable.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/19/2006 8:40 PM >>>
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/19/06 8:05 PM >>>
<snip>
>Finally, remove IFilterRelationshipAssertion and BasicFilterRelationshipAssertion.

note that we'd want to add a comparator like COMP_PROP_REL_IMPLIED_EQ to property or maybe just attribute assertions. This comparator is documented like this:
/**
  * This Comparator is used for assertions of type SubjectRelationship (and sub-types). 
  * Compares true when a tested Digital Subject has the asserted relationship (of the asserted type) 
  * whether that relationship is implied or explicit.<p>
  * For example, if the assertion specified a type of "urn:parentOf" and reference of 
  * {"someContext", "urn:Mary"} it could result in a match because either:<br>
  * A subject has a relationship attribute of type "urn:parentOf" and reference of 
  * {"someContext", "urn:Mary"), or<br>
  * A subject is referenced by the subject "urn:Mary" in the context "someContext" 
  * where the referencing relationship attribute is of type "urn:childOf" 
  * (assuming the model backing the context provides the proper inferences between 
  * parentOf and childOf)<p>  
  */
Wording is still a little rough, but hopefully conveys the idea
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top