Re: [ontology-summit] The tools are not the problem (yet)

["Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx>]

John,

 

I wrote:

 

> [EJB] ... If alternatively you turn every nominalized relationship into a class of states of affairs, then you can write Toyota asserts-actuality-of 'state-of-affairs'.  But you are now turning the ontology into microcode, or equivalently, operating on a metamodel.

 

John wrote:

 

> [JMC] fwiw I view "Toyota said" as follows. Every statement has provenance, including the source of the statement as represented by dc:source, dc:Source, prov:hasPrimarySource, prov:wasAttributedTo or prov:wasQuotedFrom. I don't see a need for a triple to be an object of another in the context of "Toyota said [something]" as it can be inferred from inspection of provenance associated with [something]. In fact I anticipate that the standard triple will in time evolve to a standard quad, the fourth item being a provenance resource. To me, systems that have a named graph as the fourth item are misguided because the named graph is the dc:subject or dc:Subject for the triple, they are just additional provenance (metalevel) information.

 

[EJB2] This is precisely treating the attribution as metadata.  The problem is that your reasoner (or SPARQL interface) will take the assertion to be true.  In Cory's example:

"Toyota said (Dashboard:Z is:within Car:Y)"

what John suggests is: Fact:  (Dashboard: Z is.within Car:Y) [source: Toyota].  But that is NOT the proposition Cory proposed.  Cory did not propose that "Dashboard:Z is.within Car:Y" is True; he only proposed that Toyota said so.  The proposition "Dashboard:Z is.within Car:Y" may be False!  The idea of evaluating the credibility of a source and using the metadata to determine whether to accept the statements of that source as fact is totally outside the reasoning process that will make inferences about Dashboards.  If I really want to include the notions Dashboard and "Statement about Dashboard" in the same reasoning process, I have to have a way of making the statement itself a member of the universe of discourse -- a member of Class/Type 'Statement'.  That was Cory's point.

 

[EJB2] In such an ontology I might actually have an 'axiom' like:  (forall (S) (if (source Toyota S) S)).   That is, if Toyota says S then S is true.  The particular problem that Fabian Neuhaus and I were working on 2 years ago was recording the contents of messages in a knowledge base that also contained known, assumed, and inferred 'facts', with the purpose of determining whether a given set of messages was self-consistent and consistent with the "known facts".  Since the object was to detect the messages that are inconsistent, the whole purpose would be defeated by assuming the entire content of a message to be facts and noting the message only as the "source" of those "facts" in metadata that does not participate in the reasoning process.

 

> ...

> [JMC] fwiw I hadn't discussed anything equivalent to "the relationship X has some dog in fight F" but it'd seem to me that in RDF-land I'd model it as below (with the understanding that Type is equivalent to rdfs:Class). Here, I restrict my use to two verbs, "is & has", although one might better use "is & involves" verbs for clarity. Anyway is this what you have in mind for this relationship:

Dogfight-Interest:Z

  is:in Dogfight:D;

  is:of Person:X;

  has:a Type:Dog.

 

[EJB2]  This is exactly what Cory meant by "objectifying the verb".  The crafted "Dogfight-Interest" is a Class/Type whose instances are actual relationships ('states of affairs').  The rest of the triples represent roles in that relationship.  (I will pass over the problems with 'has:a Type'.)

 

> [EJB] ...  And we must distinguish that case from something like (machine) requires (time) for (operation) on (material), which is intrinsically quaternary in concept.  (It can be reduced to (implemented operation) requires (time), where (implemented operation) conceptualizes the interaction of the other roles, but the table still has four columns.)

[JMC] fwiw its RDF might be

Machine-time:X

  is:for Operation:R;

  is:for Machine:Y;

  is:for Material:Q;

  must-be:this Duration:D.

 

[EJB2] Yes, but the last triple is just: X has:Duration D.   It is important to note that this 'requirement' is really a statement of fact:  It takes D minutes to perform operation R on material Q using machine Y.  In natural language we often use terms like 'require' and 'must' in stating what Ron Ross calls 'structural rules':  facts that are intrinsic to the nature of the thing, or treated as such by the "business".  Logically/semantically there is no 'modality' involved in those 'rules'.  There is no reason to treat those 'rules' as anything different from 'facts' in the knowledge base, UNLESS you somehow segregate your knowledge base into what is 'always true' and what is 'currently true'.  (In database land, the 'always true' part is nominally the 'conceptual schema', while the 'currently true' part is the 'information base', the 'data population'.  But there is the annoying phenomenon of 'ground facts' -- tables that you populate once and don't change, like this 'machine-time' one.)  The structural rules are axioms -- facts that go in the 'always true' part.  When we talk about 'ontologies', we are implicitly talking about facts that are 'always true'.   But 'always' is in the eye of the beholder -- we mean "true for all the cases we intend to use the knowledge base for".

 

Regards,

-Ed

 

 

 

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John McClure
Sent: Thursday, February 06, 2014 7:42 AM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: Re: [ontology-summit] The tools are not the problem (yet)

 

Hi Ed and Cory,
I appreciate very much your highly informative replies; please permit a few follow-up questions below as a final gesture before I drop the whole topic for want of validation within/by the group. Certainly I have no interest myself in wasting anyone's time with quixotic, though well-meaning, initiatives.  thanks again/jmc

On 2/5/2014 2:55 PM, Barkmeyer, Edward J wrote:

Cory,

you wrote:

If we take your example: "Dashboard:Z is:within Car:Y

We can also express this as a "contains-within" relation with roles such as "container", "contained". If a stakeholder were to look at one statement about one dashboard the verb form may make sense. If they were looking a lot of "contains-within" relations (say, as a car manufacturer), they would look at a table - that table may have columns for "container" & "contained".

Verb phrases are, by their nature, directional and taken from the perspective of one of the roles - in this example the dashboard. That the car contains the dashboard is another verb phrase expressing the same fact from the perspective of the car. The "inverse" style used in OWL works somewhat for binary relations but falls apart with nAry. 

[EJB]  Well, there may we be other 'readings' (Nijssen/Halpin) or 'synonymous forms' (SBVR) of the same relationship.  Semantically, 'inverse relations' are just a special case, but it happens to have a supporting mathematical notion that gives rise to viable implementation approaches.  Further, of course, any n-ary relationship can be cast as a class whose instances are states of affairs, to which each of the roles has a binary relationship that is characterized by the role, as Cory mentions below.  This has additional mathematical and implementation value.  Note, however, than in that rendering, the roles become the verbs.

Also, when we have a fact or context about one verb phrase the impact of such a statement on the other verb phrases can be difficult to compute. So if I say "Toyota said (Dashboard:Z is:within Car:Y)" then the "Toyota said" statement implicitly applies to Car:Y contains Dashboard:Z. But the underlying "fact" has now become distributed and lacks identity.

[EJB]  Be vewy, vewy caweful.  A 'fact' is a statement that is taken to be true, or a state of affairs that is taken to 'obtain' (be real).  Once you nominalize the statement, you are not taking it to be anything.  The nominalized statement may be considered to represent a class of states of affairs (situations) that may or may not have any members.  It does not lack identity -- it is exactly the class described by that statement.  The problem is whether your formal language has any way of representing the transformed statement.  In RDF land, what was added is Named Graphs.  In FOL land, you add some kind of 'nominalization' function, e.g. the 'that' operator in IKL.  If alternatively you turn every nominalized relationship into a class of states of affairs, then you can write Toyota asserts-actuality-of 'state-of-affairs'.  But you are now turning the ontology into microcode, or equivalently, operating on a metamodel.

[JMC] fwiw I view "Toyota said" as follows. Every statement has provenance, including the source of the statement as represented by dc:source, dc:Source, prov:hasPrimarySource, prov:wasAttributedTo or prov:wasQuotedFrom. I don't see a need for a triple to be an object of another in the context of "Toyota said [something]" as it can be inferred from inspection of provenance associated with [something]. In fact I anticipate that the standard triple will in time evolve to a standard quad, the fourth item being a provenance resource. To me, systems that have a named graph as the fourth item are misguided because the named graph is the dc:subject or dc:Subject for the triple, they are just additional provenance (metalevel) information.

Consider that these multiple verb phrases are traversals across the roles and between roles and the containing relation. The relation is where the identity of the fact becomes consistent. The reified relation form is essentially the "fact" that provides context for the multiple verb phrases that may traverse it. In all cases we can infer all the verb phrases implied by a reified relation. In the case of a non-qualified binary relation we can infer the reified relation from the verb phrase, but not in other cases.

[EJB]  I understand the 'reified verb' as the class whose instances are states of affairs, and every time you stuff a constant/individual into one of the roles, you get a subclass -- the ones in which that role is  played by that individual.  When you have filled all the role slots that way, you have the subclass of state of affairs that is represented by the original statement.  And yes, you can attach all of the readings/verb-phrases to the 'reified verb' class that you like.  In SBVR terms, you are talking about multiple 'representations' of the same 'concept'.  

[EJB] But there is nothing special about binary relations in this regard.  The only thing special about binary relations is that from any role-player there are only two meaningful traversals -- one to the class and one to the other role.  In a ternary relation, however, there are three such traversals -- one to the class and one to each other role.  

[EJB] Whether in fact a given pair of role players in a binary relation uniquely determines an instance of the class is quite another thing entirely.  This gets very pointedly into the semantics of the reified relation.  Are the instances of the reified relation 'states of affairs' or merely 'tuples of participants'?  (In OWL, it is the latter.)  A given pair may correspond to no instance of the class if the relation does not hold for them.  Or, it may hold for more than one instance of the class of states, seen as states, as distinct from tuples.  But again there is nothing special about binary relations -- a given tuple of the proper arity for the relation will have exactly the same properties.  This is exactly the point of relational algebra.  (Thank you, Ted Codd.)  Further the relational idea of 'projection' allows one to reduce a complex state of affairs to meaningful tuples involving fewer roles.  In so doing, a given tuple can appear more than once, representing diffe

 rent st

ates that involve the same players in those roles (while ignoring some other distinguishing role players).  For example, you can represent the relationship X has some dog in fight F by a projection of (person, dog, fight) that eliminates the dog. If you do this to a binary relation, the semantics of the result is whether X ever plays the role, and whether you can tell how many different partners X has depends on the tuple/state distinction in interpreting the reified relation.  If you do this to an n-ary relation, the equivalent existentialized role semantics (some dog) can be inferred, and at heart the binary case has the same semantics.

[JMC] fwiw I hadn't discussed anything equivalent to "the relationship X has some dog in fight F" but it'd seem to me that in RDF-land I'd model it as below (with the understanding that Type is equivalent to rdfs:Class). Here, I restrict my use to two verbs, "is & has", although one might better use "is & involves" verbs for clarity. Anyway is this what you have in mind for this relationship:

Dogfight-Interest:Z
  is:in Dogfight:D;
  is:of Person:X;
  has:a Type:Dog.

Verb phrases also contain 2 essential concepts. In your example this is "is" and "within". The "is" part qualifies the verb with a timeframe (current). If I have was:within" and "should be:within" I start to see a whole lot of verb phrases where the connection between them is not apparent. The "within" semantic is not explicit.  With a reified relation I can qualify the entire relation with "currently" or "in the past" or "as a plan for the future", etc. So one reified relation and a "tense" can provide context and a semantic for a large number of verb phrases that traverse that relation, qualified by such a tense. 

[EJB]  This is "whole nother" can of worms.  Verbs have intent, tense, mode and aspect (I think).  'Tense' has to do with time:  present, past, future.  'Aspect' is progressive vs. perfective.  'Mode' is where the 'must', 'may', 'can', 'should' modifiers come in.  If you 'qualify the relation' with any of them, you get a different relation from the 'present simple' one.  If you add a property or properties to the relation (an additional role, column), you get a n+m-ary relation that can be reduced to the original n-ary relation by 'projecting out' the tense, aspect, mode columns you added.  But, for example, a relation in which you add a timestamp role/column has the same property:  (person) is-located-in (location) at (time) is similar in almost every way to (person) (tense) located-in (location).

[JMC] fwiw it's better to use the 'at' preposition for locational relations (in fact, see the 'prov:atLocation' property). I view the 'tense' of the verb as merely a highly convenient summary of a temporal perspective, relative to a timestamp for the observed phenomena. The use of verb tense can save alot of query/computational 'work' you refer to in your next paragraph, and is amenable to a KB bot that conditionally flips tenses from will-be to is to was, as time progresses.

[EJB]  Importantly, this "modified verb" stuff is where linguistic structure, relational algebra, and formal logics start parting company, and it is all about the semantic loads of the stuff you are adding.  In relational algebras, the user who writes the query imputes the semantics to the projection.  In formal logic, I have to have interesting axioms to do that kind of thing.   But in  natural language, I recognize those particular kinds of modifiers as having common semantics over many/all verbs.  In formal logic, I have to work to provide the semantics for (tense=past), and the RDB sees no fundamental distinction between (tense=past) and (delivery-mode=rail).

[EJB]  Bottom line:  There there be dragons.  Please don't take us there.

[JMC] fwiw these predicators sure are intuitive though, and track clearly to the definition of an FOL predicate. Why is this not what FOL'ers want? Computationally you can get the same effect of a nounal predicate from an examination of the types of subject and object in a triple, so I'm still confused about this reluctance to see RDF properties be the same as what FOL properties are supposed to be --> predicators, yielding ipso facto both smaller ontologies and a more natural language... how is that not a bargain for everyone?

Where we want reusability and the ability to federate across independently conceived ontologies (and schema) we need a way to manage these different potential ways to express the same or related facts. We should also be able to represent the relationship between a verb form and a noun/role form as both will invariably be used. 

[EJB] Fully agree!

Since the reified form can provide context for multiple verb phrases I see it as essential for any reuse strategy. Also, since stakeholders will use both forms in their day to day business we must support both (and their relationship) to capture their conceptual framework in a reusable way.

[EJB]  I agree that the reified form is useful and must be supported.  Making it the cornerstone for representing verbs is less defensible.  We have to invent new verbs for the roles in reified relations, because the participations become binary facts.  So, languages like RDF and OWL only reify non-binary relations.  But RDBs reify many binary relations as well.  Further, it is not clear that what one view sees as an n-ary relation is necessarily an n-ary relation, with the same value for n, in other views.  We can understand relationships that are really the same verb with different adverbial modifiers, but we would have to be able to model that.  And we must distinguish that case from something like (machine) requires (time) for (operation) on (material), which is intrinsically quaternary in concept.  (It can be reduced to (implemented operation) requires (time), where (implemented operation) conceptualizes the interaction of the other roles, but the table still has four co

 lumns.)

[JMC] fwiw its RDF might be

Machine-time:X
  is:for Operation:R;
  is:for Machine:Y;
  is:for Material:Q;
  must-be:this Duration:D.

Regards,

Cory Casanave

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John McClure

Sent: Tuesday, February 04, 2014 1:19 AM

To: Ontology Summit 2014 discussion

Subject: Re: [ontology-summit] The tools are not the problem (yet)

Thanks Ed - I've reviewed my email and yes I see a need to change a few items but I don't think those affect the thrust of my remarks particularly that verbs are indicated "for designations for fact types - usually a verb, preposition, or combination thereof". I value this document because it provides a normative semantic for certain prepositions when used with certain verbs. What this provides to me is a very practical demonstration that an effective representation can be had that does not involve nouns within/as a predicate. Admittedly I have to study pgs 35+ to be more proficient with their vocabulary, but I think my points still stand.

I also see the issue of ontology modularization being facilitated by predicators, as I believe a simple approach is to use namespaces for tensal verbs. For example, the 'is' namespace would be a different from a 'was' namespace; each tensal namespace identifies applicable direct and indirect object properties via specification of particular prepositions, indicatives, articles and adverbs relevant to the tensal.  One's ontology merely imports the predicate vocabulary on a tensal by tensal basis. This approach does not prevent -- in fact it facilitates -- mixing tensal namespaces from different suppliers with a chief benefit being that one's property ontology is only as large as necessary for a given application, no larger.

Permit me to address the 'is part of' relation, because partitives have an obvious importance to us all. If one wants to say a certain tire is part of a car, why not use what the English language gives us: "Wheel:X is:on Car:Y" which most certainly has a different semantic than "Dashboard:Z is:within Car:Y". Under the manufactured term 'isPartOf' regime, eg "Wheel:X isPartOf Car:Y" plus "Dashboard:Z isPartOf Car:Y" you've lost semantics about the part'd relationship to the car, as a part eg is it removeable without taking the car apart, can it fall off the car and so on.... this is what prepositions provide us that is elided by isPartOf. For the inverse relations, "Car:Y has:within Dashboard:Z" and "Car:Y has:this Wheel:X".

And thanks for the noting ORM/DAMA tie-ins. OMG has a number of interesting factions.

 /jmc

On 2/3/2014 4:38 PM, Barkmeyer, Edward J wrote:

John,

I think you got an earlier version of the SBVR spec.  The "preferred terms" were changed in v1.1, because many people in someone's intended audience for SBVR recognized fact-type, etc., as terms in the ORM language, whose primary use is database design, and these folk were all about vocabularies, and wanted to distance themselves from that.  (But v1.0 in 2008 was heavily influenced by the "ORM faction" out of DAMA.)  (But now that I think of it, the publication of v1.1 was delayed by nearly 2 years by tooling problems.)

The current version is v1.2, from last fall:  http://www.omg.org/spec/SBVR/1.2.

-Ed

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John McClure

Sent: Monday, February 03, 2014 4:23 PM

To: ontology-summit@xxxxxxxxxxxxxxxx

Subject: Re: [ontology-summit] The tools are not the problem (yet)

Ed,

Thank you for raising SBVR as a source of wisdom; this substantial body of work directly supports my critique of most ontologies on the semantic web whether used for Big Data exercises or not. You mentioned SBVR's 'verb concepts' (well, you called them 'verb concept symbols') -- this term is a formal synonym in SBVR for 'fact types'. Its Annex C, SBVR Structured English states clearly that verbs are used "for designations for fact types - usually a verb, preposition, or combination thereof". Even a cursory examination of SBVR's axioms shows their rigorous use of verbs, auxiliaries and prepositions for predicates. No nouns, though, please note.

Again, my diagnosis is that an unbridled use of nouns within/as predicates causes (a) modelling problems (b) reuse problems (c) SME stakeholdership problems. This disease ("nomine praedicato") is present in many RDF ontologies and in certain FOL ontologies like Cyc Dolce et al, several referenced as exemplary ("serving as a desirable model; representing the best of its kind") by wise ones in this forum. I've tried to present this diagnosis in terms I thought would directly resonate with FOL/CL folks who live here, but the pushback feels to me furious!

As you know, I have (shared) some solutions I'm finding work well in a semantic wiki environment, but we need to agree on what the problems are first to really get into evaluating alternative solutions. If everyone thinks my analysis is way off-base, fine, I'm invested in hearing others' diagnoses (concerning why there is so little reuse/development of ontologies) including "poor tools" which, quite possibly to me alone, are merely band-aid treatments for the disorder nomine praedicato. 

/jmc

PS "is part of" is not a defined SBVR term -- I found it several times used in textual descriptions however.

On 2/3/2014 8:32 AM, Barkmeyer, Edward J wrote:

John,

The fact that is-part-of is ill-defined is not a consequence of its failing to appear in a dictionary.  The inverse relationship may be called 'contains' or 'comprises' or 'includes' or (!@#$%) 'has', and those are in English language dictionaries and they are not well-defined, either.  The problem there is just that speakers often fail to realize that there are many possible interpretations of these terms and the only way to be clear about what you mean is to provide the axioms you intend.  Of course, if your intention is vague, then the absence of clarity of the _expression_  matches the absence of clarity in the thinking.

The second problem here is about whether we are talking about linguistic structure, and that of the English (natural) language in particular, or we are talking about 'semantic structure'.  For knowledge engineering, it is really important to get past the linguistic structure and recognize the semantic structure of utterances.  In particular, the noun 'part' is a role-noun.  It is not possible for a thing to be a 'part' (except by extension).  It is only possible for a thing to be a 'part OF' something in particular.  (And it is similar in other European languages, at least, that a thing 'is-a-part' of/at/to/in.)  But that is an enforced linguistic structure; the semantic intent is subject is-part-of object.

Teaching people the English language and its grammar is a trade; and all the stuff we learned about formal models of English we learned from people who practice that trade.  Now we are talking about knowledge-engineering.  It is a different trade; and it has different formal models of 'language'.  In this trade, we use the English words to assist in conveying intent, but the "semantic grammar" is different.   

We will continue to talk past one another if we use similar grammar terms with importantly different meanings.  If 'verb phrase' can only mean what your English teacher taught you, then we will have to adopt something like the SBVR 'verb symbol' or 'verb concept wording' to make it clear that we mean something different.  (In SBVR, 'is (a) part of' is a "verb symbol"; and 'subject is a part of object' is a "verb concept wording", where 'subject' and 'object' are somehow marked as "placeholders" for "verb concept roles".  The idea is that these are the grammatical parts of semantic patterns for speech.  Noam Chomsky used different terms for the same concepts in describing the "deep structure" of natural language 50 years ago (and John Sowa will undoubtedly find similar passages in the work of Charles Peirce 100 years before Chomsky).

-Ed

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John McClure

Sent: Monday, February 03, 2014 6:57 AM

To: ontology-summit@xxxxxxxxxxxxxxxx

Subject: Re: [ontology-summit] The tools are not the problem (yet)

On 2/2/2014 2:23 PM, doug foxvog wrote:

On Wed, January 22, 2014 02:51, John McClure wrote:

John,

Please look at the predicates referenced in slides

<From%20Textual%20Entailment%20to%20Knowledgeable%20Machines,Invited%20presentation%20at%20the%20Joint%20Symposium%20on%20Semantic%20Processing%20%28JSSP%2713%29,%202013,Download%20PowerPoint%20Slides>

in several of the presentations you cited. You will see that they all

use a verb and often a preposition, with one exception (part of, which

can equally be expressed as is-within).

It's a phrase that has a different range of meanings.   The name

"isPartOf" would be a verb phrase.

[JMc] No, a 'verb phrase' by common definition includes direct and indirect objects, so "isPartOf" is not a verb phrase under that definition. There is a narrower definition (see footnote 4) but "isPartOf" fails to qualify there as well. You see "isPartOf" is a concept that cannot be found in any dictionary. It becomes anything you want it to be, depending on the day and weather. Thus freed of any anchor to an OED-based reality, you sanction artificial constructs which imo leads to modelling and interchange issues.

It can be useful within a single system to have a naming standard.

[JMc] It is more useful to have the same design approach within both FOL/non-FOL worlds, with the latter conforming to the former since data scientists' worktops & toolsets are -- from your view at least -- the ultimate destination for this information. 

All RDF properties that I've seen

-- okay, there's the exception is-a in a few ontologies -- use nouns.

This system is often for predicates that mean "has <Noun>" (with

different meanings of "have" in different cases) but with the name

also indicating the intended range of the predicate.

[JMc] Sure that intention of the property's author is clear - but the 'name' ends up being a non-word, something not in a dictionary, a concept whose meaning is merely mechanical, a programmer's concept. I say this is why ontologies are unnecessarily large, having a set of properties ill-designed because they are ill-defined.

The naming system has no bearing on the semantics -- although

maybe with the ease of a human reader to come to some level

of understanding of what was intended.

As long as the system of nomenclature is consistent for a given

ontology, that's fine.

It's no wonder that FOL'ers need to transform these models into

something more in accordance with what I cited originally in this thread

One may choose to change names from an adopted system to fit the

local nomenclature.  Or are you referring to transformations that

add semantics?

[JMc] I am referring to translations of noun-oriented properties crafted in an RDF world to verb-oriented properties crafted in the FOL world. To the extent the FOL world adopts RDF properties (principally to avoid the work of said translation) is the extent to which the FOL world is not following its own rule that predicates are verb-oriented. This is "impedance mismatch" in action (definition: a measure of the opposition caused by differences between two paradigms, especially between object-orien ted development and relational databases .... 

. 1997, Bhavani M. Thuraisingham, Data Management Systems: Evolution and Interoperation (ISBN 0849394937), CRC Press, page 33: 

Some argue that having impedance mismatch is difficult for programming intensive applications.

-- which you deleted in your original response (the guts of the original

note) to my irritation:

    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 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...

Note that the predicate *corresponds* to a verb.  That does not mean

that it *is* a verb or *must be labelled with* a verb.

[JMc] Thank you for responding to a central part of my critique. Unfortunately you're using a manufactured definition for "correspond" ... The usual definition for "correspond"  is to *have a close similarity; match or agree almost exactly* -- yours is closer to "may/might correspond", that is, you're seeing words there that don't exist. 

The matter of negation is a different, side issue in my mind. Please

comment on the fundamental criticism I am making here about the design

pattern for RDF properties: FOL's verbs vs RDF's nouns.

My comment here is "to each her own".  It is good to have a consistent

system of naming.  

However, that does not mean that one's own fantastic

system of nomenclature given by the deities and any other system is

blasphemy.

[JMc] It is NOT "MY" system of naming -- it is "YOURS". This prevailing definition of a predicate, specifically in the context of FOL and predicate calculus -- THAT IS "YOURS" my friend.  Predicate calculus and FOL are the "deities" here not me that is for sure.

Blasphemy? Ok here's an analogy. Predicate calculus is built upon the Triple Model; undoubtedly you'd cry blasphemy when presented data that accords to some weird non-conforming Unary Model. In the same way, predicate calculus is (said) built upon predicators, as I've demonstrated by reference to published definitions. I'm saying it's the predicate calculus community that should be crying "blasphemy" at the non-conforming predicates developed within the RDF community. Yet you're not, and consequently we end up with massive ontologies that SMEs (and others) find mystifying.

regards/jmc

On 1/21/2014 1:04 PM, John F Sowa wrote:

   1. See the slides and publications by the Aristo Project at AI2:

      http://www.allenai.org/TemplateGeneric.aspx?contentId=12

------------------------------------------------------------------------

On 1/21/2014 11:16 PM, John F Sowa wrote:

On 1/22/2014 12:01 AM, John McClure wrote:

How can FOL'ers not be implicitly derisive of the work RDF'ers are

diligently about, when the first reaction is to THROW IT AWAY?

That's not the point I was trying to make.  I'm sorry that I used

the phrase 'throw it away' because it was not clear what I was

rejecting.

First point:  FOL is a small subset of English and other NLs.

Any language that has the words 'and', 'or', 'not', 'some',

and 'every' can express full FOL.  We all speak FOL every day.

Second point:  I wasn't rejecting what can be expressed in RDF.

You can use RDF to describe anything that you see, hear, or feel.

Every observation in science can be described in RDF.

But RDF can't express negation.  You can't say 'not'.  And if you

take RDF and add negation, you get -- guess what -- full FOL.

Some things you can't say in RDF:

   1. Options:  you can't say 'or' in RDF, because (p or q) is

      defined as not(not p and not q) -- and RDF can't say 'not'.

   2. Rules:  you can't express an if-then rule in RDF, because

      (if p then q) is defined as not(p and not q).

   3. Generalizations:  you can express 'all' or 'every' in RDF

      because 'every cat is an animal' is defined as

      'it's false that some cat is not an animal'.

My major complaint about RDF is that it makes simple things difficult.

John

_________________________________________________________________

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/ 

_________________________________________________________________

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/ 

 

_________________________________________________________________
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/     (01)