Re: XML Schema draft populates the intersection of Language and InformationResource [ISSUE-14 httpRange-14]

Chimezie,

On 29 Sep 2007, at 02:47, Chimezie Ogbuji wrote:
>> The terms "denote", "identify", "indicate" and "mean" are used
>> interchangeably throughout the RDF specs. It's unfair to blame me for
>> this.
>
> You're right, that would be very unfair :).  I'm not blaming you in
> particular, but the *general* way in which (semiotic) denotation and
> web architecture's notion of identification are used interchangeably
> (in more places than just in the RDF specifications).
> In the long run, the ramifications for this abuse of notation are
> significant in my opinion but hard to articulate in the short term.
> They are the result of an impedance between web architecture and KR
> that is being systematically ignored.

The distinction you make seems to be too fine for many people  
(including me, unfortunately) to grasp. Care to point me to someplace  
where the mismatch is articulated?

>> The mechanism by which fragment URIs in RDF *identify* (not my choice
>> of term) are spelled out quite clearly in section 7 of rdf- 
>> concepts [1].
>
> I would argue that that particular section only attempts to reconcile
> RDF's use of URIs with RFC 2396 and that (in practice) the
> authoritative mechanism is the one outlined in rdf-mt since it is
> based on a framework (model-theory) that doesn't punt on the notion of
> reference.

Hm. I find it curious that you choose to ignore those parts of the  
relevant specifications that actually address some of the mismatch  
you posit.

>> Is there really that much of a disconnect?
>
> Yes.  Consider (as I've suggested before) if
> http://www.ihmc.us/users/phayes/PatHayes.html had a @profile which
> authoritatively identified a way to render the information about that
> page in RDF.  If the RDF included assertions that the 'thing' denoted
> by that URI is something that clearly cannot emit representations over
> the wire don't we then have a conflict?

Then Pat is simply asserting that <PatHayes.html> is a member of two  
disjoint classes. OWL and RDF allow us to do such things.

To spell it out: httpRange-14 says, if it emits representations, then  
its a webarch:informationResource. From AWWW we can conclude that  
webarch:informationResource owl:disjointWith foaf:Person. Thus, if it  
emits representations and claims to be a person, there's a  
contradiction.

What is your claim? That this is incompatible with rdf-mt?

>> URIs are governed by a paper trail of RFCs, starting at RFC 3986 and
>> leading through the IANA scheme and media type registries, then
>> through the RFCs for the different URI schemes such as http: and urn:
>> and tag:, and through a whole bunch of media type registrations, and
>> from there it bottoms out at specific data format specs such as those
>> for HTML and RDF. Thus, webarch gives us a framework that defines  
>> URI-
>> space
>
> .. snip ..
>
>> That's the framework within which RDF has to operate.
>
> With regards to those things that web-arch is *primarily*  concerned
> with, yes.  However, this is but a small subset of useful referents.
> If RDF's "universe of discourse" is restricted and dictated by web
> architecture,

I don't believe anyone made this claim. Fixing the RDF denotation of  
certain URIs does not restrict or dictate the universe of discourse.

As I said before, I *do* believe that RDF's use of URIs should be  
subject to the RFCs governing URI-space. But note that the RFCs place  
no restriction whatsoever on the denotation of large chunks of URI  
space.

Examples for URI classes without any such restrictions include:

- tag: URIs
- http:// URIs that answer 404
- large chunks of urn: and info: space.

The most interesting edge cases are http:// URIs that answer 303, and  
URIs with fragment identifier where the racine answers an application/ 
rdf+xml representation. They can denote whatever you want, but you  
should set up an associated description that tells the rest of the  
world what you intend to denote. As you know, this has certain  
benefits and certain costs, but those are a separate topic.

> this would result in a Semantic Web which would have
> *zero* value for facilitating scientific research, for instance.
>> In terms of rdf-
>> mt, I take this to mean that the denotation of many URIs (those that
>> have representations, according to httpRange-14) is fixed by the Web.
>
> Again, this makes for a very impotent knowledge representation.

Note my use of the word “many”, as in “not all”. There are enough  
URIs left to unleash the full potential of whatever knowledge  
representation you have in mind.

>> There is a school of thought that wants to see URI-space as a blank
>> slate for the purposes of RDF, completely disconnected from the role
>> of URIs on the Web.
>
> I consider myself part of that 'school of thought', however, I would
> add the caveat that where RDF URIs are used to describe the things for
> which web-arch has an unambiguous operational framwork (so called
> 'information resources'), then they should adhere to web-arch best
> practices (and shouldn't be 'disconnected').

Good, we agree on this.

> However, for everything else it is fair game to think of URIs as
> nothing more than semiotic symbols.

If the RFC that defines the particular URI scheme, and other relevant  
specs, do not place any restrictions on the nature of the things  
identified by URIs in that scheme, then yes, it is fair game to think  
of them as nothing more than semiotic symbols.

Summary: Every chunk of URI space is governed by certain RFCs, and I  
have a strong belief that any use of URIs in RDF should be subject to  
the rules and restrictions laid out by those RFC. The RFCs leave you  
enough room to do pretty much anything you want, if you use the right  
URIs. This includes building “semantic silos” disconnected from the  
Web, if this is what you want to do (though many people will tell you  
it's unwise to do so).

The benefits you describe in the rest of your post are, I believe,  
entirely attainable in a world where URIs in RDF are entirely subject  
to Web architecture, as described above.

All the best,
Richard


> Anything less, is  abuse of
> notation, short-sighted, and more of a threat to SW adoption than
> anything else (especially if we are serious about inference being part
> of the SW value proposition).  I don't mean to sound harsh (and again,
> this criticism isn't directed at you), but I don't know any other way
> to characterize the notion that RDF denotation is completely bound by
> web-arch.
>
>> Personally, I have trouble seeing the advantage
>> of this view.
>
> If you consider my modification to this view as you described it, the
> advantage is profound IMHO (and is the 'real' value proposition of the
> SW).  You can use RDF to denote 'things' that have representations
> that live in a transport protocol with very well-engineered
> operational semantics.  You can further augment these operational
> semantics with 'unambigous' assertions that are much more expressive
> than what web-arch alone can describe.  You can do so in a way that is
> consistent between intelligent agents, simple web agents, and human
> consumers.
>
> And (the icing on the cake) you can make assertions about other things
> which do not live in the transport layer (so to speak).  I would argue
> that with respect to KR, this larger class of referents is much more
> relevant.
>
> The only thing required is to drop the idea that web-arch is
> sufficiently expressive (by itself) to facilitate inference about the
> nature of a referent.  It simply is not built to do that.
>
>> If you want to operate in a universe parallel to the
>> Web, then why use URIs in the first place? Why not simply use KIF  
>> or CL?
>
> Because you can have your cake and eat it too - all that is required
> is a compromise to leave denotation to KR where it belongs.
>
>> (Although, in defense of the "parallel universe" school, this view is
>> legitimized by a passage in rdf-mt [2], which, it appears, directly
>> contradicts rdf-concepts [1].)
>
> Which particular passage do you have in mind?
>
> -- Chimezie
>
>

Received on Saturday, 29 September 2007 14:03:48 UTC