Hi Ed, (01)
Please see below. (02)
Regards,
Hans (03)
Hans Teijgeler,
Laanweg 28,
1871 BJ Schoorl,
Netherlands
www.mnei.nl (04)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Barkmeyer,
Edward J
Sent: vrijdag 24 januari 2014 2:17
To: Ontology Summit 2014 discussion
Subject: Re: [ontology-summit] The tools are not the problem (yet) (05)
Hans, (06)
Yes. It is one of my dissertations, born of increasing dissatisfaction with
the 15926 effort. And no, I won't fight tooth and nail. It solves nothing.
And finally, you are right that this is probably the wrong forum.
[HT] I shudder when thinking about how bad your tooth and nail will be if
what is below is apparently seen as mild comments by you. (07)
What I read, not so much between the lines, is that the purpose of ISO
15926, as you see it, is to define the RDF schema for a giant triple-store
of all plant lifecycle data, because someone somewhere will want to
implement that, and SPARQL will make a wonderful query language to fit his
needs. So, this is not only about knowledge engineering; this is about
database engineering using triple stores. (If integrating RDBs with triple
stores and SPARQL is your goal, you should look at the stuff Kingsley Idehen
is doing.)
[HT] On what would YOU base any knowledge, other than facts about all
aspects of the plant, gathered during decades? Not from LOD I hope. (08)
What EPCs already have is a giant relational database with several smart
front-ends that actually understand and were built to support specific
aspects of plant design and construction. What plant design software
already has is a giant hybrid database with smart interfaces for capturing
and integrating geometric design elements, and various kinds of design
views, requirements, components and sources, etc. The large firms involved
have somewhere between 20 and 50 years' experience each in plant design and
construction, and they are on their second- or third-generation software
toolset to support those activities, and they have many
megabucks/megaeuros/gigayen invested in that software. The problem is that
these people have different viewpoints and different schemas, and a lack of
standard exchange forms that cover more than bits and pieces of the data.
What does your would-be triple store have to offer them?
[HT] Ignoring your patronizing last sentence this: I have worked most of my
life in such a large firm, I have been in the trenches, I have designed the
first data bases for engineering and later the integration of data,
resulting in such software. And so did my colleagues from other large firms.
But we were faced by the fact that everybody was using something different
with different internal formats and geared to their (different) work
procedures. So when we were entering a joint venture for a multibillion
project we were discussing "your system or ours?" in order to be able to
communicate and to satisfy the growing requirements from the side of the
plant owners that they wanted all information in an integrated fashion. That
was why PIEBASE (UK), USPI (Netherlands) and PoscCaesar (Norway) we formed,
and later together in EPISTLE (Matthew West et al). So yes, we had our
systems, but these were, in a globalizing world, silos. And yes, until now
ISO 15926 is used for peer-to-peer application interfacing, succesfully as I
heard. And as I started this thread: Standardization is finding a balance
between large ego's, commercial politics, short-term thinking, hard-to-make
paradigm shifts, and for the most lack of funding. And I might add: the
unwillingness to really understand each other because that takes time. (09)
The concern is: can we develop an integrating ontology that can be used for
semantic mediation between the existing schemas, and provide a useful
exchange form based on the integrating ontology? You can think of that
ontology as the schema for your giant triple store, if you must, but the
concern of the commercial firms is to export from their existing stores in a
standard form and import into their existing stores in a standard form. And
it is not clear at all that a triple store schema is the best form of
integrating ontology for that purpose.
[HT] WE DON'T HAVE an "integrating ontology", other than the Part 2 data
model and the templates derived from that, where the latters are completely
data-driven and representing the smallest possible chunk of information.
What is different is that ISO 15926 calls for explicit information, where
most data bases (and documents) carry implicit information, making
shortcuts, that is understandable for the initiated only, but not for
computers. Examples galore: an attribute of a process boiler: "fluid
category", an attribute of a pressure vessel: "test fluid" and "test
pressure", an attribute of a centrifugal pump: "impeller diameter", etc,
etc. We are working on "patterns" that will bridge the gap between implicit
and explicit information representation. (010)
There is little motive for anyone to rewrite the kinds of power tools that
work with the existing databases so that they can work with the ultimate
integrating triple store. The exchange form is a way station on the road
between smart information sources and smart information consumers. Some
subset of the ontology may be populated directly to create new applications
at the 'handover' points. That is the kind of development that firms like
ThomasNet, for example, are already engaged in (they will find you suppliers
for products that match the design specs, using some kind of inferencing
technology). But taking another view, their work and that of their
competitors is just generating another set of incompatible schemas that work
for their particular applications, in part because their software will be
influenced by industry-specific standards for descriptions of products of
each kind (what the data they can get will look like).
[HT] You just painted the problem. (011)
There is some synergy between your goals and those of the major firms
involved, but your triple store is not on their critical path -- the common
reference ontology is the joint concern. The Big Data problem here is more
of a Big Ontology problem. There are lots of specialized pieces to a
process plant. But their critical path also involves a viable exchange
form; and a clumsy form, born of obsession with triples and upper
ontologies, will interfere with wide adoption.
[HT] Wait and see. (012)
I would just like the crew to focus on getting clean ontologies with
industry support, stop talking about methodologies and mappings between
unimportant formalisms, and let the toolsmith gang argue about the physical
exchange form for the modeled information.
[HT] Sigh. (013)
-Ed (014)
--
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 (015)
(Note: my usual disclaimer is lacking here, because this has been discussed
at NIST and it is our position.) (016)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Teijgeler
> Sent: Thursday, January 23, 2014 6:29 PM
> To: 'Ontology Summit 2014 discussion'; doug@xxxxxxxxxx
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> Hi Ed,
>
> One of your "dissertations" :-)
>
> Twelve years ago I started Part 7 with XML Schema, but that didn't
> work for me.
>
> 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.
>
> 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.
>
> 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."
>
> 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).
>
> 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.
>
> 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".
>
> Regards,
> Hans
>
> 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.
>
> -----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)
>
> Hans,
>
> Why don't we try the kind of thing that 15926 is supposed to address,
e.g.:
>
> 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.
>
> 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.
>
> This is a simplification of the RDF form of the specification.
>
> By comparison, in XML this could be phrased:
>
> <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>
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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).
>
> 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."
>
> -Ed
>
>
> --
> 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
>
> "The opinions expressed above do not reflect consensus of NIST, and
> have not been reviewed by any Government authority."
>
>
>
>
> > -----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/
>
> __________________________________________________________
> _______
> 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/7027 - datum van uitgifte:
> 01/23/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/ (017)
_________________________________________________________________
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/ (018)
-----
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 (019)
_________________________________________________________________
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)
|