W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

RE: web proper names

From: <Patrick.Stickler@nokia.com>
Date: Wed, 22 Sep 2004 11:38:52 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADCCC@trebe051.ntc.nokia.com>
To: <JohnBlack@deltek.com>, <henry.story@bblfish.net>, <www-rdf-interest@w3.org>
Cc: <h.halpin@ed.ac.uk>, <ht@inf.ed.ac.uk>

> -----Original Message-----
> From: ext John Black [mailto:JohnBlack@deltek.com]
> Sent: 21 September, 2004 18:42
> To: Stickler Patrick (Nokia-TP-MSW/Tampere); henry.story@bblfish.net;
> www-rdf-interest@w3.org
> Cc: h.halpin@ed.ac.uk; ht@inf.ed.ac.uk
> Subject: RE: web proper names
> > From: Patrick.Stickler@nokia.com
> > Sent: Tuesday, September 21, 2004 5:03 AM
> > 
> [snip]
> > One may make this assumption, and yet be wrong. Only the creator of
> > a URI can say what it denotes. And to use that URI to refer 
> > to anything
> > else is socially unacceptable behavior. People should respect 
> > the denotation
> > of a URI assigned by the creator of that URI. If the 
> denotation is not
> > clear, then either (a) ask the creator to clarify the 
> > denotation, or (b)
> > don't use that URI. IMO, this is the foundation of 
> responsible social
> > behavior on the web and semantic web.
> [snip]
> > Not if folks employ proper social manners and respect the 
> denotations
> > assigned by the creators of URIs. 
> > 
> > Wherever there is ambiguity about the denotation of a name, there
> > will be confusion. The solution is to clarify the denotation, and
> > where necessary, mint and employ new names to reinforce that 
> > clarification.
> > 
> > The problem is not in the names themselves, or how we construct
> > those names (lexically/syntactically) but in the way people
> > use the names -- and that is a social/behavioral problem, not a
> > technical one; and therefore, the solution is social, not technical.
> Social convention is one of two problems I would like to 
> comment on here, 
> the other is symbol-sense representation.
> In my view, such social manners are most fruitfully analyzed 
> in terms of 
> common knowledge using epistemic logic. When a URI denotes, 
> it does so 
> because everyone in a group knows what it denotes, and 
> further, everyone 
> knows that everyone knows what it denotes, and so on. In practice, of 
> course, this process must be bounded. But it can't be 
> avoided. 


> There has to 
> be a convention for publication of symbols (URIs in this case) that 
> establishes this common knowledge of the sense it will have 
> for the group 
> that uses it. And it is not impossible. 

Agreed. That's precisely what URIQA is designed to do.

c.f. http://swdev.nokia.com/uriqa/URIQA.html

> This is just what has 
> been going 
> on for years in the process of the creation of normative standards of 
> computer languages. It involves concession to an authority 
> such as ISO or 
> W3C, who develops consensus among a small vanguard of 
> potential users and 
> then in a process of public announcement, or Kripkian 
> baptism, network 
> effect marketing, and compliance certification entices large 
> groups of 
> human and software agents to agree on the denotation of the 
> symbols in the 
> language. Thus in HTML, the symbol "<table>" denotes a 
> certain type of 
> graphic grid layout structure to millions of browser and 
> editor software 
> packages as well as to millions of human HTML authors.

With an approach such as URIQA, though, the degree of standardization
and concensus reflected in e.g. programming languages, document
models, ontologies, etc. is not required.

Granted, the more uniformity in the terms used to communicate
the better, and we do not want to promote a needless proliferation
of synonymous terms; however, insofar as URIQA is concerned, anyone
can create any (http:) URI and publish its meaning accordingly,
and anyone else can then obtain a formal, machine understandable
description of the resource denoted by that URI. It is a tool for
social interaction on a machine level.

> In my opinion, the RDF specification is incomplete because it 
> needs to 
> include a standard for the decentralization and distribution of this 
> normative standardization process itself. In a section that 
> was ahead of 
> its time, but not correctly worked out, the working group had 
> a section 
> in the specification that would have begun this. I am referring  
> to the section about social meaning that was struck. There 
> were many very 
> strong objections to this. One was that it seems to give 
> unwarranted power 
> to organizations or individuals who would promulgate a vocabulary 
> expressing a world view obnoxious to others. This problem is 
> especially 
> acute when a URI parasitically appropriates the sense of a 
> common natural 
> language term that no one owns. This need could be addressed 
> by an explicit 
> redefine performative, which would be interpreted as legally, 
> that is, in a 
> socially acceptable because explicit manner, breaking in a 
> certain context 
> with the social conventions established for the denotation of 
> that symbol 
> by the originating authority.

My own view on the removal of this section (the striking of which
I bear significant responsibility for as it was my proposal to
strike it that carried forward) is that the technical machinery
of RDF and its social application are two very distinct issues
and should not be tightly coupled. 

That does not make the latter any less important than the
former -- only that, we had reached a degree of maturity in
concensus of the former, but not the latter, and there was
no motivating justificaiton for delaying the standardization
of the technical side of RDF, to be put into (much needed) use
while the social aspects mature in their own time.
> The other problem to be solved is how to represent the 
> denotation of a 
> symbol in a useful, machine readable manner. This is the what 
> that is known 
> when common knowledge is established. This problem is far 
> more complex that 
> it seems. The attempt to build machine readable, usable 
> dictionaries has 
> defied solution for years. And it may never be achieved. Take 
> a symbol 
> such as John Black, denoting me, I say. What does it mean to know the 
> denotation of that symbol? If you receive a file in the FOAF 
> vocabulary, 
> with my IFP mailbox, do you know me? How could I ever represent what 
> that symbol denotes to me? For starters I would need to include a 
> complete autobiography, copies of all my art work, etc. What does it 
> mean to my mother, to my friends, to people on this list? There 
> is an immeasurable difference in the quality and quantity of 
> descriptive 
> material associated with this symbol and known to these 
> individuals and 
> groups.

Well, the problems involved in using string literals as identifiers,
even in conjunction with IFPs, are far more complex than using URIs
as identifiers.

And insofar as URIs are concerned, approaches such as URIQA
specifically address the issue of "what does this URI mean?"
in a formal, machine understandable manner.

> Never-the-less this too can be done to an extent, useful for many 
> different purposes. Last week I began collecting such machine 
> readable 
> representations of symbol senses on a wiki page at 
> http://kashori.com/wikiPim/CategoryBoundedDescriptions. Among those 
> I have collected so far are:
> 	ConciseBoundedDescriptions
> 	InverseFunctionalBoundedDescriptions

OK. I see that you have already encountered URIQA.

> 	ChattyBoundedDescriptions
> 	DefinateDescriptions
> 	DiscriminantDescriptions
> 	OntologicalClosure
> 	PublishedSubjectIndicators
> 	WordnetSynsets
> and now
> 	WebProperName
> This last proposal appears to address some of these issues. 
> It includes 
> the concept of a naming authority, with a Kripkian baptism, and 
> yet shows how it can be distributed. It concisely collects as little 
> or as much of the descriptive properties of the entity denoted by the 
> name and shows how to collect them in a concise structure. 

Well, I guess I should hurry up and read the oft referenced paper on 
web proper names...

Received on Wednesday, 22 September 2004 08:41:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:52 UTC