- From: pat hayes <phayes@ihmc.us>
- Date: Thu, 2 Oct 2003 11:11:18 -0500
- To: "John Black" <JohnBlack@deltek.com>
- Cc: <public-sw-meaning@w3.org>
> > -----Original Message----- >> From: pat hayes [mailto:phayes@ihmc.us] >> Sent: Wednesday, October 01, 2003 5:34 PM >> To: John Black >> Cc: public-sw-meaning@w3.org >> Subject: Re: Thought experiments on a proposed solution >> >> >> >I would like to propose the following solution to this >> >issue. >> >> What issue, exactly? > >Tag issue rdfURIMeaning-39. > >> Im not aware of any problem that needs >> to be solved here. >> >> > We create a specification for the Semantic Web >> >Conformity Relation (SWCR), a binary relation where each >> >tuple contains one element from the set of all URIs and one >> >element from the set of all classes defined in any ontology. >> >> Well, there's a problem right there. Most classes >> don't have definitions, and most ontologies don't >> define anything. >> > >Ok. Let's replace "defined" with "mentioned". But how is it possible to keep track of this? Anyone can use a URI in any ontology. The very word 'ontology' may be misleading here, in fact, since we anticipate, surely, that the SW will largely comprise SW-style markup, i.e. machine-readable content at Web sites put there in order to render content accessible to machine reasoning. In this scenario, 'the ontology' could be any of these or indeed any subset of them, so the potential number of 'ontologies' could be of the order of 2|n where n is the size of the Web. That is, if, as you suggest, an 'ontology' is defined to be some set of downloadable SW assertions which *mention* a given URI. > >> When are people going to get this straight?? >> Almost all the words we use in English and almost >> all the URIs we use in RDF/OWL *do not have* and >> *do not need* definitions. All this trying to >> lock down unique meanings in registries is a >> COMPLETE FANTASY, like trying to capture a bowl >> of mist or pin a label onto a breeze. Give UP on >> it, for goodness sake. Even if we were to set up >> some such world-wide registry, after unbelievable >> effort, it would be immediately ignored by >> everyone, and quite correctly so, since it would >> not provide any actual utility to anyone that >> they can't get just by using the Web in the way >> that people are already using it. We would do >> better to spend our time doing fantasy gaming: it >> would use up about as much time and have about as >> much connection with the actual world, but be a >> lot more fun. >> >> Pat Hayes > >I am not proposing any such registry, so these arguments >are as specious as they are caustic. Sorry you got a blast of impatience, fueled by frustration; and sorry if I read your message too quickly. But I don't think the basic point is specious. I don't see any reason for us to invent protocols or really do anything other than describe existing, or perhaps better emerging, practice in such a way that we do not accidentally screw anything up. To try to do more is, at this stage, folly. The world in general has not yet started using SW technology seriously, so we do not yet know how it will actually evolve. Chances are it will not in fact go exactly how any of us envision at present. However, what is certain is that much of the current thinking about it is based on naive or just plain mistaken views about semantics and meanings, eg. that URIs must have unique ones, and that these mistaken views are the primary motivation for wanting to make sure that things happen 'properly'. So even if you do not use the M-word, the very idea of there being a need to associate URIs with ontologies in some 1:1 manner by ANY means is, I suggest, based ultimately on a deeply flawed view of what constitutes the meaning of a URI on the SW. (I do not mean to say that you share this view, only that the design you suggest may be inspired by it.) > As I say below, >this relation is virtual, it would have a similar status to >"...a network-spanning information space consisting of >resources, which are interconnected by links defined within >that space." > >I can also delete any mention of the word "meaning" from the >proposal without harm. It is simply a virtual association >between two keys. OK, so let me make my point in a direct way: why only two? What if I want to virtually associate a URI with, say, a particular set of ontologies? Or with a historical trail of ontologies, changing as the world they describe changes? (Rather like a resource as opposed to the representation-sets it emits as a function of time, cf. the REST architecture.) Or with all and only the SW assertions made at any present or future time by any employees of Thingie Corp.? Or any site maintained by the State of Florida? Or something else again, such as the people I tend to agree with? What if a virtual community wants to set up a mutually-referring group of connected sites in which each of them shares the burden of defining the meanings of their URIs with all the others? I thought of those in about 2 minutes: I'm sure the planet as a whole will come up with a few more in the next decade or so. >Use of this protocol would be optional, there is no suggestion >of locking down anything or limiting anyone in any way. > >I believe there would be enough utility to drive its voluntary >use. I guess I can hardly object to a system for voluntary use. But is it, really? Or would it be more like a protocol which SW tools will require in order to function properly. After all, TAG groups are understood to speak with an unusual degree of authority. >It is simply a summary of ways for everyone to agree on >how to link URIs up with metadata that mentions those URIs. >But it does so in a minimalist manner, giving it maximum >versatility. It would enable every user of URIs to personalize >the metadata configuration on every web page they publish. But only in a highly restricted way, inspired by a fundamentally flawed view of what the role of metadata on the SW is likely to be. (For the record, the very idea of 'metadata' seems inappropriate in this context. Most SW content is simply data.) > To >do so lets people express themselves better. People are driven >to be understood. That is the utility. > > >> >The ontology element is specified either by the owner of the >> >URI or by default. This binary relation may be virtual >> >and certainly will be decentralized, a federated creation > > >of the combined efforts of every one who participates in >> >the optional Semantic Web Conformity Protocol (SWCP). >> > >> >Now some thought experiments: >> >1) How does this relation get populated? >> >An RDF tag specifying the ontology:type of the URI is: >> >1.a) embedded in the document at that location. OR >> >1.b) is in an RDF document that embeds >> >(wraps) the document found at that location, possibly with >> >new mime type. OR >> >1.c) an MGET function is called on the URI which returns a >> >document containing the tag. OR >> >1.d) some form of redirection takes place and the document >> >at that location contains the tag. OR >> >1.e) some form of content negotiation takes place and >> >locates a document containing the tag. OR >> >1.f) other solutions are possible. OR >> >1.g) all else fails, the URI defaults to type >> >ontology:http-resource, which is a class in an ontology of >> >the present hypertext web. >> > >> >2) But what if the URI contains a hash mark? >> >One of the methods listed under number 1 will have to be >> >applied to each such URI and performable from the URI with >> >the hash mark removed. >> > > > >3) What about RDDL? >> >Instead of putting the RDDL document at the endpoint of >> >the URI, there would be an ontology:namespace tag there. The >> >actual location of the RDDL document would then be located >> >according to the location method defined by that namespace >> >class. That definition could well say, look up the html >> >document at that URI. But this would no longer be necessary >> >due to the level of indirection afforded by the SWCR. If I >> >want the type of the URI to be myOntology:myNamespace, then >> >my definition may specify that the RDDL is located elsewhere. >> > >> >4) How about Sandro's 4 RDF programmers requirements? in >> >http://lists.w3.org/Archives/Public/public-sw-meaning/2003Sep > > /0088.html >> >r1) All URIs are now logical constant terms with solid grounding >> >in the sw, including those that have not been typed. For those >> >now constitute a large set of statements of the form "that >> http-resource". >> >Those URIs that have been typed by the owner have as simple >> or complex >> >a meaning as the owner wants. >> >r2) have a human readable web page - The class of the URI can be >> >defined to point to such a page, along with an access method to it. >> >r3) a web address for RDF/XML content - Similar to r2, the class >> >of the URI can have a Property giving the location of an RDF dump >> >for any URI in that class, as well as a path to it. >> >r4) the address of a query answering service - Similar to r2,r3. >> >In general we use the power of this new technology to create classes >> >of URI that will do whatever we want. >> > >> >5) What does using an URI require of me and my software? as asked in >> >http://lists.w3.org/Archives/Public/public-sw-meaning/2003Sep >> /0054.html >> >You must look up a URI in the SWCR and make sure that your use of the >> >URI conforms with the type as defined by the owner. If >> molly wants to >> >use sally:123 and abide by the optional Semantic Web >> Conformity Protocol >> >(SWCP), then molly looks up X in SWCR(sally:123,X). >> >Suppose X = domesticAnimals:cat, then molly can use sally:123 as a > > >domesticAnimals:cat or a domesticAnimals:mammal or as a >> >domesticAnimals:animateBeing. But Molly will violate the >> optional SWCP >> >if she uses sally123 as a domesticAnimals:dog. Why? Because everyone just *knows* that domesticAnimals:dog and domesticAnimals:cat are disjoint? Or because this can be determined by machine inference processes? The former hardly seems sufficient for the SW, and in any case what if Sally never actually said that domesticAnimals:cat means the same as the English word "cat" (which would be a very risky claim to make, by the way, in any case.) If the latter, is Sally obliged to say enough in her ontology to ensure that this kind of contradiction must be mechanically detectable? (Almost certainly impossible, since Sally has no control over what Molly is asserting, eg Molly might have said that dogs are a subset of cats, or might have just started talking about foozles, using her own URI, without being precise about what phylum they are in. ) If not, who is to say which of Sally and Molly is really right? One problem is that there is no way, even in principle, to distinguish between a disagreement over content and a disagreement over reference. Take the marriage example: are the devout christian and the pragmatic atheist disagreeing about facts, or about the meaning (referent) of "marriage" ? There is no way really to tell; the only way to resolve that issue is for them to get together and agree on a mutually acceptable terminology. Maybe Molly and Sally just use words differently. Another problem is that inconsistency is labile. Maybe M's and S's ontologies are consistent but when both are added to Smithsonian:DefinitiveZoology they together produce a contradiction. Now who is wrong? >Lets say that Molly's >> >reputation according to SWCP will move lower a notch, people >> will give >> >her a lower SWCP-trust-rating. >> > >> >6) How does this answer Tim's request in New Issue - Meaning >> of URIs in >> >RDF documents? as presented in >> >http://lists.w3.org/Archives/Public/www-tag/2003Jul/0022.html >> >6.1) It's a concise statement of a number of architectural elements. >> >By objectifying the requirements with the virtual SWCR, many goals >> >are simply stated. >> >6.2 It gives guidance on some specific questions, such as what is >> >a SWCP compliant tool required to do when using someone's URI - look >> >it's meaning in the SWCR and conform to it. >> >6.3.a It clarifies certain points. URIs have a single > > meaning, that is, >> >the X in SWCR(URI,X). That is the fundamental mistake, right there. They don't, they won't, and we should stop trying to find ways of maintaining this fantasy that they should or must. To the extent that tag issue rdfURIMeaning-39 is based on this assumption, it needs to be corrected, not implemented. >It is the URI owner that puts the defining tag >> >in the SWCR. >> >6.3.b Consistent misuse of a URI results in a lowering of >> the reputation >> >of the misusers - not in a change of the meaning. >> >6.3.c The use of a URI implies conformance to the SWCR as described. So, as I suspected, this is not voluntary; it has become part of the architecture. Merely using a URI will imply a commitment to this absurd idea that URIs have unique meanings. Any of these proposals will make the SW into a large-scale but conventional software design, rather than the social/semantic experiment it could be. That would be a shame, to put it mildly; in the medium to long run, it means that the SW will either break, or (more likely) blandly ignore what the TAG group has been saying. Pat Hayes > > >When in doubt you look it up in the SWCR as described above. >> >6.3.d Setting the defining tag in under the control of >> whoever controls >> >what is located at that URI. >> > >> >John Black >> >Senior Software Architect >> >Deltek Systems, Inc. >> >13880 Dulles Corner Lane >> >Herndon, VA 20171 >> >JohnBlack@deltek.com >> >703-885-9646 - Office (Tues,Wed,Thur) >> >434-964-1936 - Home Office (Mon,Fri) >> >434-825-3765 - Mobile (Anytime) >> >> >> -- >> --------------------------------------------------------------------- >> IHMC (850)434 8903 or (650)494 3973 home >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32501 (850)291 0667 cell >> phayes@ihmc.us http://www.ihmc.us/users/phayes >> >> -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ihmc.us http://www.ihmc.us/users/phayes
Received on Thursday, 2 October 2003 12:11:34 UTC