[wg11-owl] Goal of the review

[ewallace at cme.nist.gov]

Ed Barkmeyer wrote:

David Price wrote:

>> As a start, there are multiple ways in which OWL might be used by SC4. As
>> OWL is built on RDFS and RDF, it may also be appropriate to consider some
>> use of those languages as well.
>
>We do need to talk about RDF, not because SC4 uses it, but because OWL 
>does, and because certain SC4 applications might use it in lieu of, or 
>in addition to, OWL.  RDF is essentially a general-purpose knowledge 
>representation format with very few pre-defined semantics.  Knowledge is 
>a set of triples (Subject, Verb, Object), and there are a handful of 
>predefined relationships (verbs), which include is-an-instance-of (IN), 
>is-a-kind-of (SUBTYPE), and IMPLIES, AND, and OR.  The rest is 
>roll-your-own.

RDF does not include predefined properties for logical IMPLIES, AND and OR.
(Don't confuse RDF with N3.)  AND is implicit for any set of statements about 
the same resource.  I don't think that there is anyway to say OR.

>The emerging W3C SDAI-like stuff is aimed at RDF, with possible OWL 
>specializations.

Are you referring to SPARQL here?


>> Seems like there are at least four uses:  > > 1 - As a language for
>>defining general purpose, universal semantic > repositories similar to
>>what 15926 provides for the Oil and Gas industry.
>
>The intent of OWL, as I understood it, is to be a language for defining
>the information content of a Web resource (which is what RDF was for).
>If "defining universal semantic repositories" means defining a model of
>all the objects and properties that are interesting in a particular
>industry area from a particular perspective, then, yes.  OWL, EXPRESS
>and SQL are languages in which you can do that, and each has its own
>strengths and weaknesses.

OWL is intended to enable semantic markup for resources.  By resources
we mean anything that could be named by a URI. This is not limited to
information resources.  So I could describe my MINI and not merely data 
on the web related to it.  Of course, the OWL description itself IS just
data on a/the web ;).  

I agree that OWL provides just another way to model a domain.  That model
can enable certain kinds of machine reasoning, but to keep that reasoning
tractable OWL's expressivity has been kept quite limited.

>> 2 - As a language for defining taxonomies to be used with the External_class
>> modules in STEP, etc.
>
>Yes!  Properly used, OWL provides a means of *defining* taxonomies in a 
>way that lets one reason about the classification of an object from its 
>known properties.  One can represent these ideas in EXPRESS, but nothing 
>in Part 11 defines that kind of interpretation.  Unfortunately, the 
>limitations of OWL as a "rules language" will greatly limit the possible 
>specification of classification rules.
>

Agreed, although this may overly emphasize the expressivity limitations of
OWL.  Furthermore, the taxonomies can still be created in OWL without being
able to specify the necessary and sufficient features that distinguish some 
classes.  One could then use some other, web friendly, logic language to define 
these distinguishing axioms as an extension to your current models.  Of course, 
this is the bleeding edge of the Semantic Web with no real standards and many 
potential issues.  I wouldn't go there just now.  But the hooks will be 
there to do this later when this is more mature.

>This approach could also be used to revamp the IRMs, or to "define" SC4 
>"module" MRMs as well.

>> 3 - As a modeling language for domain-specific ontologies (i.e. schemas) as
>> done in STEP today, Mandate, etc.
>
>Yes, but in that regard, OWL is more abstract than EXPRESS and generally 
>less competent.  Its primary advantage is the one mentioned in (2) 
>above.  Most of the EXPRESS rules language has no rendering into OWL. 
>Some careful RDF extensions to OWL, particularly in the area of 
>mathematical functions, would allow us to capture the principal ideas 
>that EXPRESS rules state, although rarely in the way they are 
>conceptualized in EXPRESS.  (But I hold no hope that SC4 would have the 
>competence to develop those extensions.)

Um... I guess I don't really understand what is being described by 3.  
ontologies and schemas are two different things (throwing out the RDF
usage of "schema", which just confuses things).  OWL is not a data modeling
language and probably shouldn't be used as such.  But neither is EXPRESS
an ontology language, although I would guess it would be easier to go from
an EXPRESS schema to an OWL ontology than from an OWL ontology to an EXPRESS 
schema.


>> 4 - As an implementation language with the concepts of Class, Property and
>> Individual, standard XML and other encodings, industry query languages, and
>> industry APIs.
>

Ah.  Tool support is what David is alluding to, I think.  Support for 
visualization, querying, serialization, conversion, ontology development
and more.  OWL has this and more is being developed all the time.  The
question is though, "Is the functionality and quality of this tool support
what is needed for manufacturing data exchange?"  Frankly, David is far
better situated to answer that question than I am.  If he thinks this
tool support is useful, I will take his word for it.

>The standard "implementation" ("exchange form") of OWL is a collection 
>of RDF triples.  I assume that is what David means.  Query languages and 
>interfaces like KQML are not OWL-specific, and SPARQL is RDF-specific, 
>not OWL-specific.

The normative exchange form for OWL is RDF/XML [1].  So RDF parsers,
triple stores, and query interfaces all can be reused for OWL.  Description
Logic reasoner support requires OWL, and the major editing tools were
built specifically for OWL (Protege-OWL plugin and SWOOP).

>Yes, if you render EXPRESS entities into OWL classes, and EXPRESS 
>(explicit) attributes into OWL properties, then you can do data exchange 
>with OWL-defined RDF triples.  And some knowledge engines will be better 
>prepared to consume that form than Part 21 or XMI.  And if you are 
>building knowledge repositories whose interface is KQML or SPARQL 
>instead of SDAI or SQL, you will want the OWL-RDF format.  Now as to 
>"industry" query languages and "industry" APIs, the current state is 
>competing draft standards implemented as academic hacks fronting 
>academic engines, with a few fledgling EAI-like products emerging.
>
>But from the point-of-view of moving information into and out of 
>manufacturing software applications as we know them, OWL-RDF is just yet 
>another ugly data form.
>
>I don't deny the potential here, but the state of the practice in 
>"implementation" in OWL land is SC4:1992.  In 5 years, half of the 
>standards may be supported by niche products.  But there will be more 
>tools than industrial applications.

I doubt that SC4:1992 is comparable to the current state of OWL tool support.
This is because OWL leveraged past work in RDF and Description Logics, and
because development was fueled by major research initiatives on both sides of 
the Atlantic.  There are a number of academic and commercial implementations
of OWL reasoners and triple store development frameworks.  The quality of
some of the these tools is quite good and is having a strong influence on
the functionality and APIs of their competitors.  If and how this will
translate to manufacturing application support for OWL is anyones guess.

-Evan





[1] RDF/XML Syntax Specification
   http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/