Hi Ed, (01)
One of your "dissertations" :-) (02)
Twelve years ago I started Part 7 with XML Schema, but that didn't work for
me. (03)
I read between your lines that in your mind ISO 15926 is for application
interfacing only. But that's not so. It happens, but it's not the ultimate
goal.
The title of the standard is "Industrial automation systems and integration
- Integration of life-cycle data for process plants including oil and gas
production facilities".
How do you integrate all the diverse historical information about a plant
from concept to demolition over a period of decades? Not with XML. (04)
Add to that that during a large EPC project a multitude of parties, spread
around the globe, not always knowing English well enough, work on the same
plant and need to share data over the internet. (05)
We still have much work to do on the reference data library, which for the
most is a taxonomy-only now, but by adding templates over the years must
grow to a workable ontology.
When one defines requirements he/she can use specializations of such
templates. Our target is what we have seen passing by on this forum for the
last couple of days, and so eloquently worded by you:
"You have to determine that the definition is unambiguous, in terms of the
definitions of the English words used and the syntactic (and pragmatic)
context of their use. Then you have to determine whether that is exactly
what you mean for your particular purposes." (06)
For the mapping of application data, from their proprietary format to ISO
15926 format, Ian Glendinning came with the concept of "patterns". These are
words/concepts that software folks and engineers use in their software and
reports. In the US the IIP folks are working on that and they have come up
with a large list already. These are mapped to one or more interrelated
templates with some fill-in-the-blanks fields. I expect that hat list will
evolve in a kind of engineering dictionnary (with standard mappings). (07)
Finally this: the reason for chosing RDF and OWL was not reasoning or
inferencing. No manager (in our business) in his right senses will accept
the outcome of that as the basis for engineering. Besides, our world is that
of the plant owners who will certainly not agree with any "open world"
scenario. This is his lifecycle information, and no one shall get to that
other than on a need-to-know basis with all due secrecy agreements. Very
closed. (08)
So it will boil down to fairly straight forward data storage and retrieval
in triple stores, be it with the semantic rigour and possibilities of ISO
15926. No fixed data model. And because of the mapping at the source, before
storage, any data mining will be much easier than that requiring the usual
"cleansing". (09)
Regards,
Hans (010)
PS Before you start fighting the above tooth-and-nail, consider whether this
is the right forum for that. I don't know, quite honestly. (011)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Barkmeyer,
Edward J
Sent: donderdag 23 januari 2014 23:05
To: Ontology Summit 2014 discussion; doug@xxxxxxxxxx
Subject: Re: [ontology-summit] The tools are not the problem (yet) (012)
Hans, (013)
Why don't we try the kind of thing that 15926 is supposed to address, e.g.: (014)
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. (015)
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. (016)
This is a simplification of the RDF form of the specification. (017)
By comparison, in XML this could be phrased: (018)
<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> (019)
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. (020)
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? (021)
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. (022)
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. (023)
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. (024)
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 abl e 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. (025)
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). (026)
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). (027)
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." (028)
-Ed (029)
--
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 (030)
"The opinions expressed above do not reflect consensus of NIST, and have
not been reviewed by any Government authority." (031)
> -----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/ (032)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/ (033)
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/ (034)
-----
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2014.0.4259 / Virusdatabase: 3681/7027 - datum van uitgifte:
01/23/14 (035)
_________________________________________________________________
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/ (036)
|