Hans, (01)
Why don't we try the kind of thing that 15926 is supposed to address, e.g.: (02)
The discharge pressure of the Pump that is designated P-101A in the design
specification (Dow-A47-2013-rev2) must be at least 5000 kPa. (03)
We can say that there is a PossibleIndividual PI-1 that fulfills this
requirement.
PI-1 is a Pump.
PI-1 instantiates the class C-1.
C-1 is a DesignElement
C-1 has designation "P101A"
C-1 is a part of PS-1.
PS-1 is a PlantDesign ...
PI-1 has a required property RP-101.
RP-101 is a discharge-pressure
RP-101 is greater-or-equal to Q-101.
Q-101 has unit KPa
Q-101 has ratio 5000. (04)
This is a simplification of the RDF form of the specification. (05)
By comparison, in XML this could be phrased: (06)
<rdl:PlantDesign id="PS-1" name="Dow-A47-2013-rev2">
...
<rdl:DesignElement id="C-1" designation="P-101A" type="Pump">
...
<HI50.7:minimumDischargePressure unit="KPa" value="5000" />
...
</rdl:DesignElement>
...
</rdl:SystemSpecification> (07)
Note that the content of these two forms is the same, and the degree of formal
definition in the two is approximately the same as well! Further, it doesn't
take much in the line of a transformation tool to convert the second form to
the first, if that is what is wanted, but the reverse is more complex: it
involves matching a pattern that doesn't have a formally defined structure.
And the second form can be much more readily transformed into whatever the
internal form is in the software system being used to manage the plant
construction. (08)
And what are we expecting to be the value of the RDF? Well, if a Pump
manufacturer exports a similar description of his Pump designs (Pump classes),
then some engine could infer that PI-1 "is an instance of" one or more of those
Pump classes, which is to say, "P-101A could be satisfied by" such a Pump.
Does anyone seriously think that that inference would be a great deal more
difficult if the data were exchanged in the XML form? And more importantly,
did the plant construction firms and the eventual plant owners express a desire
to import the design specification into such an inference engine, as distinct
from their SAP system, for example? (09)
As an identifier for a concept: HI50.7:minimumDischargePressure with the
appropriate xmlns assignment has exactly the same IRI properties as
http://HydraulicInstitute.org/HI50.7#minimumDischargePressure, and the same is
true of the rdl: entries. And OBTW, they both have the same formal definition,
in English. Further, both of these approaches -- the RDF ontology and the XML
schema -- provide similar "context" for the use of the term. But the XML
schema directly associates that term with certain other required information
units with data types, while the RDF form does not. (010)
For LinkedOpenData, the RDF form may be preferable, in that it doesn't
prejudice what kinds of information can be attached to that symbol. But for
exchanging plant construction requirements, we very much want to prejudice the
kinds of information that MUST BE attached to that symbol. (011)
The problem here is that the RDF syntax was chosen because it is au courant
among some knowledge engineers, not necessarily because it was appropriate to
the problem. Other knowledge engineers have made do with XML inputs, mapped
them to a reference ontology, e.g. in OWL, and made whatever inferences they
needed using that ontology and whatever inference engine was appropriate to
their task. (012)
The concern of many ISO 15926 folk is that such an XML Schema is tied to a
specific point in the lifecycle, whereas some of the conceptual elements in it
can be reused at other points in the lifecycle, in which the corresponding
information exchanges will have different forms. And that is where the reuse
issue becomes interesting. It is important to be able to reuse the symbol in a
different context, knowing that the meaning of the symbol is the same. But
surely that is about defining the information element properly, and importing
it, using whatever capability your chosen language allows, into the
ontology/schema for the lifecycle phase of interest. The property is the same,
regardless of what item has it. At the same time, there is a difference
between a design requirement, a product characterization, and an in-operation
measurement, all of which are USES of the property, and the context of use does
condition the meaning of the utterance. So, it is important to be able to
define the data element independently, but to formally contextualize it in a
usage, and I don't see RDF having a clear advantage over XML in that regard. (013)
The value of using an au courant software technology is that you can find
programmers who know how to use it. But you have to choose a technology that
is consistent with what the user wants to do, and thus be aware of what the
programmers are going to be asked to use it for. I don't see that RDF is
particularly well-suited to the problem of plant information exchange among the
major software tools used to design, build and manage a plant. The idea that
reasoning tools will somehow be a part of that process in the near future is
worth investigating, but it is not what the users need now. And the RDF forms
being proposed may not be ideal for commercial inference tools in that area
when they appear (which was David Price's point). (014)
What is most wanted from the 15926 academic efforts is a solid reference
ontology for process plant components and their properties, expressed in a
language that suits that purpose reasonably well, like OWL. Doing that
properly requires the participation of many experts in various component
domains and a standardized approach to making OWL models. It is a no-brainer
to agree that 'FittingType' is a 'class of classes of inanimate physical
object', and saying that has nearly no value. The interesting coordination
problem is whether the OWL form is a set of subclasses or a set of individuals
(so that two working groups will produce similar structures) and whether the
concept is the same for Pump fittings and Valve fittings (whether the two
working groups can use a common ontology module). (015)
I have gotten really tired of activities whose primary interest is in
developing new tools and philosophical upper level ontologies and development
methodologies. If you want to produce something of value to industry,
formalize the concepts in a real application domain. As the late Selden
Stewart once observed, "By definition all information technology is meta-work.
It follows that standards for information technology is meta-meta-work, and
methodologies for the development of standards for information technology is
meta-meta-meta-work. The more 'metas', the further from any practical value to
anyone." (016)
-Ed (017)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division
100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800 (018)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (019)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Teijgeler
> Sent: Thursday, January 23, 2014 4:41 AM
> To: doug@xxxxxxxxxx; 'Ontology Summit 2014 discussion'
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> Doug,
>
> I have a question to you, and I am in doubt whether it is appropriate to put
> that forward in this forum. If inappropriate, please reply in private.
>
> You wrote: "Other computer scientists do not limit methods/routines to
> having exactly two arguments. Of course, they see this box RDFers put
> themselves in as counterproductive."
>
> Implementers of ISO 15926 are in that box, they struggle with the seeming
> incompatibility of that standard and RDF, because ISO 15926 has the concept
> of Relationship:
> QUOTE
> A relationship is something that one thing has to do with another (see
> 5.2.11 and Figure 187). In this part of ISO 15926, a relationship is defined
>as
> the classification of an ordered pair. The pair is repeated to record another
> relationship. No two relationships of the same classification have the same
> pair in the same order. The order enables roles to be assigned to the related
> things.
> UNQUOTE
>
> Examples:
> * Classification with roles classified (shall be a Thing) and classifier
>(shall be a
> Class)
> * RelativeLocation with roles located (PossibleIndividual) and locator
> (PossibleIndividual)
> * Composition with roles part (PossibleIndividual) and whole
> (PossibleIndividual)
> etc.
>
> We also have ClassOfRelationship, one meta level up, and even
> ClassOfClassOfRelationship one more up.
>
> Relationship instances can be addressed by other instances of Relationship,
> such as: "this marriage (relationship) is a same-sex marriage
>(classification),
> and it is not approved (relationship) by John Doe"
>
> In the jargon of RDF these Relationships are a kind of 'reified' properties.
> In pure RDF, for information storage, we have made a workaround, but
> when we want to use OWL for reasoning we seem to have a problem,
> because this does not fit in the OWL mould (so some experts claim). Yet to
> us, representatives of parties involved in the process industries, the
>addition
> of the ISO 15926 meta model to OWL is adding semantic precision.
>
> My question to you is whether or not ISO 15926 Relationships can be treated
> as owl:Class, be it that these owl:Classes have two predefined rdf:Properties.
> Does that make reasoning impossible?
>
> Regards,
> Hans
> www.15926.org
>
> PS Oh BTW, we also have MultidimensionalObject, which is an entity type
> with a list of 2 - many predicates, but I didn't want to boil the ocean :)
>
> __________________________________________________________
> __________________
> ______________________________________________
>
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of doug
> foxvog
> Sent: donderdag 23 januari 2014 7:35
> To: Ontology Summit 2014 discussion
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> On Tue, January 21, 2014 17:28, John McClure wrote:
> [text below; commented on parts here]
>
> > There are two competing notions of the *predicate* in theories of
> > grammar
>
> I.e., there are two meanings, and the same word is used for each.
>
> People should realize that such cases are not competing notions of some
> thing, but multiple notions, with the unfortunate use of the same label for
> the different things.
>
> > The first concerns traditional grammar, which tends to view a
> > predicate as one of two main parts of a sentence, the
> > other part being the subject;
> > the purpose of the predicate is to modify the subject.
>
> I would disagree with this "purpose" claim. That isn't what traditional
> grammar claims about this notion of "predicate".
>
> > The second derives from work in predicate calculus (predicate logic,
> > first order logic)
> > and is prominent in modern theories of syntax and grammar. In this
> > approach, the predicate of a sentence corresponds mainly to the main
> > verb and any auxiliaries that accompany the main verb, whereas the
> > arguments of that predicate (e.g. the subject and object noun phrases
> > are outside the predicate. [wikipedia
>
> This second meaning is that which we are using in ontologies. Note that in
> this meaning, the predicate "corresponds mainly" to verbs -- is different from
> saying that the predicate is a verb. Here we have gotten away from natural
> language and need not be concerned with verbs. If we choose to express a
> statement in a natural language, we can choose to map the predicate to a
> (set of) verb(s).
>
> Note also that this definition does not require there to be exactly two
> arguments. There may be one, two, or more.
> * S V
> * S V O
> * S V DO IDO
>
> > If (1) rdf:Statement = rdf:subject + rdf:predicate + rdf:object, then
> > to which of these "competing notions" does rdf:predicate refer?
>
> It is a subset of the second meaning, with exactly two arguments.
>
> > If you say
> > the former, then I maintain the formulation should be (2)
> > rdf:Statement = rdf:subject + rdf:predicate.
>
> So this is not the meaning.
>
> > If you say the latter, then WHERE ARE THE VERBS
>
> As mentioned above, definition 2 predicates *correspond* to verbs -- they
> don't need to be verbs. Therefore i will take your "VERBS" to mean
> predicates.
>
> Thus, the VERBS are the binary predicates used in each embedded sentence.
> * rdf:about
> * rdf:Property
> * xml:lang
> * rdfs:label
> * rdfs:comment
> * rdf:resource
> * rdfs:domain
> * rdfs:range
> * rdfs:subPropertyOf
>
> > - why do we see predicates defined like
> > <rdf:Property rdf:about="&p3p;purposeOptIn">
>
> Because of the syntax used.
>
> >why on earth is this thing called a "Statement"?
>
> It is a "Statement" because it is a set of statements that are interconnected,
> some being used as arguments to others and some being implicitly anded. A
> sentence diagram for this statement is quite possible, though complex.
>
> It is a single sentence because the predicate rdf:about relates
> "&p3p;purposeOptIn" to a single property which happens to be a set of
> properties.
>
> > In short, the entire body of predicates defined by the [RDF]
> > "ontologist community" to-date are fundamentally flawed.
>
> Flawed as a body, yes. But i suggest this does not mean that each individual
> predicate is flawed. The requirement to use only binary predicates is the
> flaw -- it is the hammer that is the chosen tool to solve every problem.
>
> > It's small wonder SMEs look
> > askance at ontologists and their gee-whiz ideas; in their gut, they
> > know something is amiss.
>
> Other computer scientists do not limit methods/routines to having exactly
> two arguments. Of course, they see this box RDFers put themselves in as
> counterproductive.
>
> > (Note: this perspective is completely scoped within the RDF, where
> > many of us 'practitioners' must wallow, so replies of 'use CycL'
> > are simply unresponsive to the needs of what, 95% of the people in
> > this forum.)
>
> I suggest removing the "must". One might use RDF as a communication
> standard, but that does not mean that an processing must be done using it
> (other than converting between it and a more accessible form).
>
> Why wallow?
>
> -- doug
>
> > =============================
> On Tue, January 21, 2014 17:28, John McClure wrote:
> > John Sowa et al,
> > <rant>I do agree SMEs' stakeholdership in an ontology is key to what
> > ails us. But the problem is with the way we create ontologies; until
> > we grapple with that, "better tools are the answer" is merely lipstick
> > on a pig. SMEs certainly /should/ recoil at stuff like:
> >
> > <rdf:Property rdf:about="&p3p;purposeOptIn">
> > <rdfs:label xml:lang="en">purpose(opt in)</rdfs:label>
> > <rdfs:comment>
> > Data may be used for this purpose only when the user
> > affirmatively requests this use.
> > </rdfs:comment>
> > <rdfs:domain rdf:resource="&p3p;Statement"/>
> > <rdfs:range rdf:resource="&p3p;PurposeClass"/>
> > <rdfs:subPropertyOf rdf:resource="&p3p;purpose"/>
> > </rdf:Property>
> >
> > No amount of tools, in my humble opinion, will /ever/ hide this
> > odiferous _crap_. I strongly suspect that I could pull equally useless
> > *properties* from whatever ontology is being hoisted on a pedestal,
> > and effortlessly mock it too. IOW the way we use the RDF is thoroughly
> > corrupt. Why/how? Here's the nub.
> >
> > There are two competing notions of the *predicate* in theories of
> > grammar <https://en.wikipedia.org/wiki/Grammar>.^[1]
> > <https://en.wikipedia.org/wiki/Predicate_%28grammar%29#cite_note-
> 1>
> > The first concerns traditional grammar, which tends to view a
> > predicate as one of two main parts of a sentence
> > <https://en.wikipedia.org/wiki/Sentence_%28linguistics%29>, the
> > other part being the subject
> > <https://en.wikipedia.org/wiki/Subject_%28grammar%29>; the purpose
> > of the predicate is to modify the subject. The second derives from
> > work in predicate calculus (predicate logic
> > <https://en.wikipedia.org/wiki/Predicate_logic>, first order logic)
> > and is prominent in modern theories of syntax and grammar. In this
> > approach, the predicate of a sentence corresponds mainly to the main
> > verb and any auxiliaries that accompany the main verb, whereas the
> > arguments <https://en.wikipedia.org/wiki/Verb_argument> of that
> > predicate (e.g. the subject and object noun phrases
> > <https://en.wikipedia.org/wiki/Noun_phrase>) are outside the
> > predicate. [wikipedia
> > <https://en.wikipedia.org/wiki/Predicate_%28grammar%29>]
> >
> > If (1) rdf:Statement = rdf:subject + rdf:predicate + rdf:object, then
> > to which of these "competing notions" does rdf:predicate refer? If you
> > say the former, then I maintain the formulation should be (2)
> > rdf:Statement = rdf:subject + rdf:predicate. If you say the latter,
> > then WHERE ARE THE VERBS - why do we see predicates defined like
> >
> > <rdf:Property rdf:about="&p3p;purposeOptIn">
> >
> > And if you were to say neither, then I ask why on earth is this thing
> > called a "Statement"? Can we not stop making words up that suit
> > arbitrary purposes?
> >
> > In short, the entire body of predicates defined by the "ontologist
> > community" to-date are fundamentally flawed. It's small wonder SMEs
> > look askance at ontologists and their gee-whiz ideas; in their gut,
> > they know something is amiss. (Note: this perspective is completely
> > scoped within the RDF, where many of us 'practitioners' must wallow,
> > so replies of 'use CycL' are simply unresponsive to the needs of what,
> > 95% of the people in this forum.)
> >
> > </rant>
> >
> >
> >
> __________________________________________________________
> _______
> > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > Subscribe/Config:
> > http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> > Community Wiki:
> > http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
> > Community Portal: http://ontolog.cim3.net/wiki/
> >
>
>
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/
>
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2014.0.4259 / Virusdatabase: 3681/7024 - datum van uitgifte:
> 01/22/14
>
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/ (020)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (021)
|