Re: ShEx relation to SPIN/OWL

On Jul 31, 2014 4:07 PM, "Arthur Ryman" <ryman@ca.ibm.com> wrote:
> It was designed to provide a highly reusable vocabulary. There are very
few constraints imposed by DC Terms and this makes it very reusable. For
example, consider dcterms:title. In one application dcterms:title may be a
required property while in another it may be optional. So where do you put
those constraints? They do not belong in the DC Terms vocabulary. You need
another place to define constraints and associate them with the
application.

[Assume w.l.o.g. that we are only considering standardized OWL semantics.*]

If an axiom is part of the core meaning of a term then it belongs in the
core  ontology.  For example, if it is part of the definition of the term
'bicycle' in the ontology that it must have exactly two wheels, this axiom
belongs in the core ontology. Unicycles are thus excluded.
Bicycles with 'training wheels' attached may or may not qualify, based on
how 'training wheels' are defined.

Removing a core axiom from the ontology does not provide more opportunities
for *reuse* ; it provides more opportunities for *misuse*.

If an axiom is not part of the core meaning of a term, then it does not
belong in the core ontology.  If there are no meaningful cardinality
constraints on the number of titles a thing can have then they don't belong
in the core ontology.

Fortunately it is possible to build new, more restrictive ontologies that
reuse and restrict existing ontologies. If one wishes to describe a world
where bicycles can only have wheels with spokes (e.g.  things with solid
wheels are not within the meaning of 'bicycle') , one can use an import
statement to include the axioms from another ontology, then add the
additional axioms that commitments only in this new ontology.

If you are engaged in an information fusion task, the more precise the
definitions used in the shared ontology, the more feasible the task
becomes.  The more diverse the information contexts become the less useful
generic terms become.

Having a broad  property named "health" is useless if in one part of the
organization it refers to having up to date vaccinations , and in another
it refers to the whether an aircraft is ready to deploy.

Simon

[*ICV in fact requires that constraint axioms be in a separate 'imported'
ontology, but that is orthogonal to my point].