Re: Thought experiments on a proposed solution

>I would like to propose the following solution to this
>issue.

What issue, exactly? 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.

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

>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. 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).  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.
>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

Received on Wednesday, 1 October 2003 17:33:41 UTC