On Tue, May 28, 2013 19:06, John McClure wrote:
> On Fri, May 24, 2013 11:53, doug foxvog wrote:
>>On Thu, May 23, 2013 00:34, jmcclure@xxxxxxxxxxxxxx wrote: (01)
>>> I really appreciate the amount of your time and the depth of
>>> your responses to my questions - you've sharpened my
>>>understanding of a
>>> few things (and thanks for the name inspiration). I hope you
>>> benefitted also. (02)
>>So far, i have been confused by this syntax. (03)
>>> * Grover is a vocabulary of properties - of prepositions plus
>>> tenses of 'to-have' (04)
>>The above sentence the syntax you used was created prior to your email
>>including it. I did a few quick web searches but found
>>nothing applicable for "Grover model". (05)
>>Could you please provide a link to a document formally specifying
>>the vocabulary and syntax and explaining the semantics of its
>>statements?
>
> JMc: Right I am developing this model now and, with your help!, am
> understanding what needs to be in such document. ... (06)
>>> * explicitly built atop RDF's model ..... "a
>>> Resource instance HAS instances of Properties"
>>> * with
>>> "loosely-coupling predicates" to reduce the size of ontologies, their
>>> costs and scariness (07)
>>I have found what i've seen so far quite scary.
>
> JMc: "Scary" is a monstrous ontology that is one-half bloated (08)
Yes, Cyc is bloated. 12 years ago they had terms defined off in
topical "microtheories", so that reasoning that didn't need those
topics had no access to the terms. Unfortumately, imho, they
created a top-level ontology and moved much of the definitional
information there. (09)
> by unnecessary predicates like "hasFather" and "isFatherOf"
> IN ADDITION TO concepts like "Father". (010)
Cyc avoids inverse relations. In some cases, they allow the
inverse version as syntactic sugar for the first with arguments
reversed, but all internal representations use a single form. (011)
Creating a "role" for each predicate does not remove the bloat.
It merely results in the bloating of roles instead of predicates. (012)
Note that Cyc predicates have argument restrictions and inter-
argument restrictions. Other ontology languages conclude a
thing's type based on how it is used in predicates. Thus a typo
can change a thing's type. (013)
Cyc also has predicates that can conclude a type; but they are
used more infrequently. (014)
For example, here are restrictions:
(isa father BinaryPredicate)
(arg1Isa father Animal)
(arg2Isa father MaleAnimal)
(interArgIsa1-2 father HomoSapiens MaleHuman)
and a conclusion:
(arg2Isa-Inferred father
(SubcollectionOfWithRelationFromTypeFn MaleAnimal father Animal)) (015)
I don't find any #$interArgIsa-Inferred predicates in OpenCyc. I thought
they existed, but maybe they were removed from OpenCyc. (016)
> Such replication is a sure recipe for turning users OFF as they
> contemplate learning a foreign vocabulary of predicates
> plus a vocabulary of
> common nouns that the system understands (too). Users find massive
> reference ontologies scary
> simply because they're being asked to promote a black box
> they can't see inside. (017)
Agreed. Compartmentalized ontologies are far less scary. (018)
> The 'wiki way' is to bring ontologies down to earth, to enable people to
> create additions to it themselves, not necessarily requiring
> costly/academic ontologists. (019)
Would you trust your business/satellite to an ontology that was created
by untrained people? (020)
How is this different than saying that you have no need for costly
programmers? (021)
>>> * A vocabulary intentionally trivial for anyone to
>>> self-master (022)
>>That may be for a person who reads a document defining the vocabulary
>>and syntax. Why you have provided so far is not intuitive enough to
>>understand, nor similar enough to any of the dozens of computer/data/
>>ontology languages that i have learned for me to be clear of
>>its meaning. (023)
> JMc: this is unfair to say. I am using triples syntax to state EXACTLY
> what is meant (024)
I'm sure that was your intent. (025)
I meant that I was unable to figure out what your triples meant.
I have programmed for over 4 decades and developed ontologies
since 1996. (026)
What i am saying is that you need to define your vocabulary and
syntax. I am not saying it is not trivial to master once the student
has these explained. (027)
> What you may find difficult to understand are the non-opaque
> names of the resources I am referencing as subject and as object.
> It's a very simple naming convention,
> the same as used in wikis, perhaps the most
> populated kind of datasets on the planet. Wiki pagenames are
> namespace:pagename,
> which I have cast as type:topicname, (028)
This uses the same syntax for a very different semantics. The syntax
namespace:pagename provides an abbreviation for a longer page name;
the namespace can be arbitrarily selected, but it is useful to standardize
it so that people who read the namepace abbreviation in one place will
recognize it in another. (029)
The syntax type:topicname seems to have the semantics that topicName
is an instance of type. (030)
> where the topicname can be type:topicname
> itself, leading to constructs like
> <Father:Person:John McClure>. (031)
So the form is <type:(type:)*topicname>, with the semantics that
topicname is an instance of each of the types. Do the following
three lines have the same meaning?
<Father:Person:John McClure>
<Person:Father:John McClure>
<Person:John McClure> and <Father:John McClure> (032)
> Granted I caused a little confusion using the double-bracket
> syntax native to wikis, eg [[Father:Person:John McClure]], but I see also
> <>
> syntax used so I've adopted that to speak with you more effectively, on
> your terms. (033)
All i need is the syntax explained. The style of brackets does not matter,
although i'd prefer the close brackets to be in same style as the open
brackets. (034)
>>> * A vocabulary intentionally suitable for modelling
>>> document content
>>> * Grover is a vocabulary of categories - of
>>> adjectives & adverbs
>>> * that uses a highly useful naming scheme...
>>> type:topic-name ... (see ISO Topic Maps) (035)
>>How does [[Sister:Person:X]] correspond to this? (036)
> JMc: This is a reference to a resource about Person:X's role as (a)
> Sister. (037)
Once it is known that X is a person, could [[Sister:X]] could be used with
the same meaning? (038)
Or are you using "Person:" also as a namespace? This would mean that
you could reference Dog:X and Person:X and be referring to two different
things. This would mean that Animal:X would have no relation to either.
[It would also mean that the answer to my questions above about the
order of types is that they would be fixed.] (039)
I would suggest against having the syntax with double semantics:
both providing a type and a namespace. (040)
> Work is needed on resource names to handle when multiple instances of
> sisterhood exist for Person:X. (041)
I can see that this would be a problem.
In this case you might use a binary functional notation:
[Sisterhood;Person:X;Person:Y] (042)
>>> * that implements the syntax
>>> seen here eg past(Statement) must(Statement) etc (043)
>>Where is the missing argument in these statements? The first
>>statement is past relative to what time? The second statement
>>is required according to what authority?
>
> JMc: Past is related to today, now, present. The exact moment the resource
> is a "past" resource is indicated by properties of the resource,
> presumably
> created by a bot that daily inspects current resources for . Authority is
> indicated by properties of the resource too, via perhaps a "per" predicate
> coupled with an Authority resource, (044)
OK. (045)
"per" means "has as authority"
Similarly:
"of" means "is an instance of type"
"for" means "first argument of role/predicate is"
"has" means "second argument of role/predicate is"
"from" means "source for role existence is"
"in" means "part of" with the type of "part" depending upon argument types
"on" means "date of event" if the argument types are appropriate.
"must have" has a meaning depending upon its argument types.
These should be spelled out before the term is used. (046)
I don't see a preposition for "is a subclass of". You might use:
"under" means "is a subclass/subtype of" (047)
These meanings, and any others that you use, should be specified
in the language definition. The teaching materials could provide
an example of each preposition, followed by its general definition,
with a caveat that rules can be created for certain argument types
which would alter the meaning of the predicate for such uses. (048)
> eg (049)
> <Course:Econ 101> of <Type:Course>
> <Course:Econ 201> of <Type:Course>
> <Course:Econ 201> must have <Prerequisite:Course:Econ 201> (050)
What type of reasoner would interpret this "must have" to mean
that any student must have passed an instance of the class
<Prerequisite:Course:Econ 201> before being permitted to take
<Course:Econ 201>. (051)
I suppose that this is a rule on the type Course and the role
Prerequisite. (052)
> <Prerequisite:Course:Econ 201> of <Type:Prequisite>
> <Prerequisite:Course:Econ 201> on <Date:Publication:2013 Course Offerings> (053)
I think the "Date:" belongs in a new line in this format. I.e.,
<Prerequisite:Course:Econ 201> from <Publication:2013 Course Offerings>
<Publication:2013 Course Offerings> of <Type:Publication>
<Date:Publication:2013 Course Offerings> of <Type:Date>
<Date:Publication:2013 Course Offerings> for <Publication:2013 Course
Offerings>
<Date:Publication:2013 Course Offerings> has <Year:2013> (054)
> <Prerequisite:Course:Econ 201> for <Course:Econ 201>
> <Prerequisite:Course:Econ 201> has <Course:Econ 101>
> <Prerequisite:Course:Econ 201> per <Authority:Department:Economics>
> <Authority:Department:Economics> of <Type:Authority>
> <Authority:Department:Economics> for <Department:Economics>
> <Department:Economics> of <Type:Department>
> <Department:Economics> in <School:The Johns Hopkins University> (055)
I note that other schools' economics departments would have to be
named differently. (056)
> <School:The Johns Hopkins University> of <Type:University>
> <Type:University> of <Type:School> (057)
Do you mean "kind of"? Up to this point "of" meant "instance of". (058)
>>> John Sowa's right that
>>> "RDF and most versions of logic are not polymorphic"
>>> meaning that prepositions' semantic rules would,
>>> under Grover, depend on the types of
>>> subject & predicate nodes present in a triple. (059)
>>One could create a theory that can do this:
>> (if
>> (and
>> (PRED X Y)
>> (type X TypeA)
>> (type Y TypeB))
>> <Statement>) (060)
> JMc: Here's my ignorance on full display: I have no idea whether this is
> correct! (061)
>>> But I don't use a
>>> property's name/range/domain as validation criteria, (062)
>>Thus data entry error could not be caught by a type violation. (063)
> JMc: Sorry, there are other ways to do type validations during data entry, (064)
Wouldn't they rely on defining the permissible types for the property? (065)
> and anyway it's a poor user interface that allows a user to enter type
> violations in the first place. (066)
??? If input allows the use of a keyboard instead of merely selection
from a menu, there is a possibility of a mistyped key. (067)
If a user interface asks for a numeric input, what prevents the user
from typing in "what"? Does the keyboard lock up if an inappropriate
character is typed? (068)
>>> I see them as
>>> indexes to the formalisms, in other words, I presume the validity of
>>> relationships, looking up applicable formalisms as needed -- I think
>>> that's what's meant in part by an open-world model. (069)
>>Open-world does not mean "anything goes". It means that the knowledge
>>base is not omniscient. E.g., if the KB has information that Barack
>>has a daughter named Sasha, that doesn't mean that Barak has only
>>one daughter. (070)
> JMc: Agreed however you overlook the OWA nature of the operational
> ontology itself --
> namely, one that defines a Type:Daughter but not a Type:Son does
> not mean that there is no Type:Son, and hence should a Son
> instance exist within a graph, it is not NECESSARILY an error.... (071)
I suggest that ontology definition stage should be separate from
knowledge base definition stage. Otherwise, the same type or
predicate could be entered in the KB several times with different
names (possibly just misspellings) with no way of knowing that
it was happening. (072)
>>> So, as 'polymorphic properties'
>>> seem Sowa's only technical concern, and as I
>>> expect little effort dealing with those, I see no
>>> impedimentto bringing a Grover front-end
>>> to my semantic wikis. To the extent he & others
>>> believe that Grover is not a recommended practice, (073)
>>Who has recommended it? Is it an ISO standard? (074)
> JMc: no not an ISO standard (although it seeks to incorporate ISO Topic
> Maps). I am creating this ontology for use in semantic wikis, by normal
> people. If the ontology is superior, then as computational ontologists,
> you'll have to deal with seeing this kind of ontology as it's used more &
> more in practice, should we be so fortunate.
>
> -- John -- (075)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (076)
|