Re: Learning from other disciplines?

On Fri, Feb 27, 2009 at 12:56 PM, Pat Hayes <phayes@ihmc.us> wrote:
>
> On Feb 26, 2009, at 6:01 PM, Alan Ruttenberg wrote:
>
> On Fri, Feb 27, 2009 at 3:15 AM, Pat Hayes <phayes@ihmc.us> wrote:
>
> On Feb 26, 2009, at 8:57 AM, Alan Ruttenberg wrote:
>
> 2009/2/26 Booth, David (HP Software - Boston) <dbooth@hp.com>:
>
> Hi Alan,
>
> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>
> The AKT example in that note seems to me to be in the wrong direction.
>
> The problem is that there is no theory of what AKT is. Here is a
>
> theory: AKT is some class of proteins, instances of which are
>
> individual protein molecules. Later it is discovered that there are
>
> various subclasses (no surprises - any class can have subclasses, and
>
> even AKT, before the "splitting" could be considered to have
>
> subclasses - for instance those that were phosphorylated).
>
> When these subclasses are discovered, one adds ... subclass axioms.
>
> AKT1 subclassOf AKT.
>
> Yes, it is true that in the scenario described, if AKT had been modeled
>
> as a class rather than as an instance, the relationship between AKT and
>
> AKT1, AKT2 and AKT3 could have been expressed merely as a subclass
>
> relationship.  That is an important point.  But the point of this scenario
>
> is not to debate whether Jann *should* have modeled AKT as a class or an
>
> individual.  The point is that, as long as individuals are used, they will
>
> sometimes be ambiguous (at least to some applications -- they may be precise
>
> enough for others), and in such cases we need a way to deal with it without
>
> breaking existing applications.
>
> This is where we disagree. I don't think we should be spending our
>
> time teaching people hacky workarounds for poor modeling. We need to
>
> spend our time having people think clearly about modeling in the first
>
> place.
>
> This however presupposes that (1) there are clear, universally applicable,
>
> rules of 'good' modeling, and (2) that someone knows what they are. At the
>
> present time, (2) is clearly false, and (1) is seriously doubtful: all the
>
> evidence suggests otherwise. Quite awful views on what is "good" and what is
>
> not (such as insisting upon the close-to-incoherent distinction between
>
> continuants and processes, based on idiosyncratic views held by a small
>
> cabal of philosophers and based on late-19th century phenomenology) have
>
> been already incorporated into deployed standards, for example, where they
>
> will cause harm to interoperability for years, probably centuries, to come.
>
> Pat,
>
> This has nothing to do with continuants versus processes
>
> I know, it was just my favorite example of a bad idea which is widely
> recommended as good modeling practice.
>
> , and yes, I
> do think there are some rules of good modeling
>
> Can you write them down? Seriously, if you really think these exist, it
> would be a valuable resource.

There are some for the OBO Foundry: http://www.obofoundry.org/crit.shtml
I often summarize:

Document what terms mean by tracing them to elements in reality. Or
say when you are not.
Have a theory of what an instance is.
Work out how instances stand in relation to one another – what are
their properties.
Define classes as instances with shared properties
Figure out how to document and organize all this knowledge in a way
that can be managed in a distributed manner.
The product of this effort is an ontology
Use the ontology to structure knowledge and data you wish to share with others

Others:
Don't confuse words with the entities they denote (one of David's mistakes).
Every term deserves a little thought. (how often is this one ignored?)

There are a bunch of things I've learned about building ontologies
with others. For instance, don't argue about names - figure out
definitions and then give names later.

Yes it would be great to have a resource of the various lessons we've
all learned.

>
> , of which thinking is a
> first prerequisite. This AKT example has been mentioned too many times
> and it is clear that independent of any 'introduced' ambiguity, the
> modeling choice is unexplained and incoherent from the getgo. No
> amount of patching will fix it.
>
> Well, it sounds like the basis of the issue here is whether to model
> something as a class or an individual. As a general question, this arises
> quite frequently. The "best" thing to do has no obvious answer, because it
> depends on the formalism you are using. There is no single, clear answer
> which works in all cases. If you use a decently expressive language, the
> question is meaningless: so it evidently is not an ontological question.

The question is certainly not meaningless. It goes to the question: of
what are you speaking.

> I note that David given *no* definitions for any of the terms he uses.
> Shall we at least agree that minimal documentation of the terms one
> uses, in natural language, is a universally applicable good modeling
> practice? At least when attempting to write in a scholarly way about
> modeling?
>
> Documentation, but not definition.

Hardly. It reads to me like a recipe for a magic potion.

> If you believe that ambiguity can be entirely eliminated by "good practice",
>
> then I venture to suggest that your advice will be one of the enduring
>
> problems for future knowledge workers.
>
> I don't believe I said that. I said that in this case one needs not
> bring in any new terminology to see what's gone wrong - that applying
> basic knowledge of how to model (starting with saying what your
> instances mean) leads to a situation in which one needs not introduce
> Dave's hacky solution.
>
> And this will be true pretty much
>
> independently of the advice itself, because whatever you tell people to do,
>
> other people will choose, for excellent reasons, to do the opposite.
>
> Sure, and there will be people claiming that the earth was created
> 5000 years ago. They just shouldn't be doing science.
>
> Bad analogy. Modeling isn't doing science; and there isn't a science of
> modeling (yet).

Modeling has to head in that direction. Maybe I think there's more of
a shot at that than you do. At least we have to act like we're trying.
When I read some of your messages they strike me as advertising: don't
worry, model how you like, no standards necessary, don't use any
criteria to evaluate what you've done....

-Alan

> Pat
>
> -Alan
>
>
> Pat Hayes
>
>
>
>
> Otherwise we land up with a same as historical mess of incommensurate
>
> data dressed up in a brand new syntax.
>
> -Alan
>
>
> I've updated the scenario to make this clearer:
>
> [[
>
> It is worth noting that in this particular scenario, the problem that
>
> Jann and Luke face could have been averted if they had initially modeled
>
> these genes as classes rather than as individuals, because then AKT1, AKT2
>
> and AKT3 could simply have been subclasses of AKT.  Indeed, modeling things
>
> as classes does help avert -- or at least postpone -- this kind of issue,
>
> though it may create other issues.  However, the point of this scenario is
>
> not to debate Jann's modeling decisions, it is to illustrate how this
>
> ambiguity issue can be addressed when it does arise.  Thus, we need to
>
> assume that, for whatever reason, Jann did what he did, and Katie's
>
> application then depended on Jann's definitions.
>
> ]]
>
>
> Separately one has terminology. The word "AKT" was initially only a
>
> label for AKT. Later it also became a label for AKT1. No surprise
>
> again - words are notoriously ambiguous.
>
> Yes, that happened historically, but it is irrelevant to the point of the
>
> AKT scenario I described.  I've clarified the note at the beginning to
>
> indicate more clearly that the scenario I describe was merely *inspired* by
>
> the history of AKT, but the details are fictional: "This scenario was
>
> inspired from the actual history of AKT.  However, the names and other
>
> details are completely fictional."
>
>
> There is no need to introduce these *completely undefined* relations
>
> s:isBroaderThan etc. There *is* a need to understand and use existing
>
> *defined* mechanisms, such as rdfs:subClassOf and rdfs:label, in this
>
> case.
>
> rdfs:comment wouldn't be a bad idea while we're at it.
>
> I don't understand why you say that these are undefined.  They are
>
> defined in a later section of the document, as noted, using rdf:comment:
>
> http://dbooth.org/2007/splitting/#isBroaderThan
>
> [[
>
> s:isBroaderThan a rdfs:Property ;
>
>   rdf:label "isBroaderThan" ;
>
>   rdf:comment """s:isBroaderThan indicates that the subject URI
>
>       has a URI declaration that is broader than some URI declaration
>
>       of the object URI.  (See s:isBroaderThanDeclaration.)
>
>       This is a convenience property:
>
>       Since a URI could have more than one URI declaration,
>
>       this property makes weaker statements than
>
>       s:isBroaderThanDeclaration. """ ;
>
>   rdfs:domain xsd:anyURI ;
>
>   rdfs:range xsd:anyURI .
>
> s:isNarrowerThan a rdfs:Property ;
>
>   rdf:label "narrows" ;
>
>   rdf:comment """isNarrowerThan is the inverse of s:isBroaderThan.""" ;
>
>   rdfs:domain xsd:anyURI ;
>
>   rdfs:range xsd:anyURI .
>
> ]]
>
> Did you want some other kind of definition?
>
>
>
> David Booth, Ph.D.
>
> HP Software
>
> +1 617 629 8881 office  |  dbooth@hp.com
>
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not
>
> necessarily represent the official views of HP unless explicitly so stated.
>
>
>
> -Alan
>
> On Thu, Feb 26, 2009 at 4:39 PM, Michael Hausenblas
>
> <michael.hausenblas@deri.org> wrote:
>
> Thanks David!
>
> Re http://dbooth.org/2007/splitting/ - yes, I'm aware of it
>
> (actually
>
> bookmarked it on delicious on 26 Jan 2009 ;) and of course
>
> I read it.
>
> I must admit that when I read your note I didn't really
>
> get/see this point.
>
> My bad, sorry.
>
> @Jonathan: as there are at least two people around that
>
> think into the same
>
> direction and maybe some more that could imagine this can
>
> solve some of our
>
> issues around httpRange, IR, etc. - how about adding it to
>
> the TAG F2F
>
> agenda? Or is it too late? Too vague?
>
> Cheers,
>
>     Michael
>
> --
>
> Dr. Michael Hausenblas
>
> DERI - Digital Enterprise Research Institute
>
> National University of Ireland, Lower Dangan,
>
> Galway, Ireland, Europe
>
> Tel. +353 91 495730
>
> http://sw-app.org/about.html
>
> http://webofdata.wordpress.com/
>
>
> From: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
>
> Date: Tue, 24 Feb 2009 22:06:53 +0000
>
> To: Michael Hausenblas <michael.hausenblas@deri.org>, AWWSW TF
>
> <public-awwsw@w3.org>
>
> Subject: RE: Learning from other disciplines?
>
> Michael,
>
> That sounds similar what I've been arguing for quite a while:
>
>  (a) Ambiguity is unavoidable. (Pat Hayes has articulated
>
> this point much
>
> better than me though.)
>
>  (b) The ambiguity involved in failing to distinguish
>
> between an IR and a
>
> non-IR is not fundamentally different than other kinds of
>
> ambiguity.
>
>  (c) Something that is adequately clear and unambiguous to
>
> one application may
>
> be ambiguous to another application, because different
>
> apps have different
>
> needs.  A URI such as http://markbaker.ca/ that denotes
>
> both a person and a
>
> web page may be perfectly fine for an application that has
>
> no need to
>
> distinguish between IRs and non-IRs, but it may cause
>
> confusion and havok to
>
> an application that relies on such a distinction.
>
>  (d) Therefore, there is no need to view such
>
> IR-versus-non-IR ambiguity as a
>
> violation of web architecture, though it may be a
>
> violation of good practice.
>
> These points are explained a but further in
>
> http://dbooth.org/2007/splitting/#httpRange-14
>
>
>
> David Booth, Ph.D.
>
> HP Software
>
> +1 617 629 8881 office  |  dbooth@hp.com
>
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not
>
> necessarily represent the official views of HP unless
>
> explicitly so stated.
>
>
> -----Original Message-----
>
> From: public-awwsw-request@w3.org
>
> [mailto:public-awwsw-request@w3.org] On Behalf Of Michael
>
> Hausenblas
>
> Sent: Tuesday, February 24, 2009 8:39 AM
>
> To: AWWSW TF
>
> Subject: Learning from other disciplines?
>
>
> All,
>
> This is a crazy idea, but please give it a thought before
>
> rejecting it ...
>
> As far as I gather 'we' sort of fail to agree if we
>
> should/can define IR and
>
> non-IR or even if we need to differentiate between documents
>
> and abstract
>
> things at all. One could now try to understand the problem
>
> from a totally
>
> different point of view by learning from quantum mechanics.
>
> You are surely aware of the waveparticle duality [1]? So why
>
> can't we try
>
> to apply the same idea here. We can say, for example,
>
> that for a given
>
> application/use case the distinction between IR and non-IR
>
> makes no sense at
>
> all and hence is useless; all that counts at the end of the
>
> day are some
>
> bytes and maybe some metadata that we can get over the wire.
>
> In other cases
>
> one thing may be abstract or one thing may be a document. The
>
> Web version of
>
> the 'waveparticle duality'-equivalent would then render sort of:
>
> ===
>
> The 'document-thing duality' addresses the inadequacy of
>
> classical concepts
>
> (from the operating system domain, software development,
>
> etc.) like
>
> "document" and "abstract thing" in fully describing the
>
> behaviour of
>
> Web-scale objects.
>
> ===
>
> Comments, anyone?
>
> Cheers,
>
>      Michael
>
> [1] http://en.wikipedia.org/wiki/Wave-particle_duality
>
> PS: Jonathan, thanks a lot for your detailed comments re the
>
> dependencies
>
> visualisation - I will address them in a separate mail (esp.
>
> the n^2 table
>
> approach - I like it ;)
>
> --
>
> Dr. Michael Hausenblas
>
> DERI - Digital Enterprise Research Institute
>
> National University of Ireland, Lower Dangan,
>
> Galway, Ireland, Europe
>
> Tel. +353 91 495730
>
> http://sw-app.org/about.html
>
> http://webofdata.wordpress.com/
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------
>
> IHMC                                     (850)434 8903 or (650)494 3973
>
> 40 South Alcaniz St.           (850)202 4416   office
>
> Pensacola                            (850)202 4440   fax
>
> FL 32502                              (850)291 0667   mobile
>
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>

Received on Friday, 27 February 2009 04:29:37 UTC