- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 26 Feb 2009 21:56:58 -0600
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, Michael Hausenblas <michael.hausenblas@deri.org>, Jonathan Rees <jar@creativecommons.org>, AWWSW TF <public-awwsw@w3.org>
- Message-Id: <C4512F2A-7B74-4FC0-9A6C-43FA8FA53751@ihmc.us>
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. > , 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. > > 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. > >> 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). 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:02:27 UTC