W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2003

Re: Outside our charter, was: Schema LCC review

From: Frank Manola <fmanola@mitre.org>
Date: Wed, 15 Jan 2003 07:41:05 -0500
Message-ID: <3E2556E1.9050703@mitre.org>
To: Jan Grant <Jan.Grant@bristol.ac.uk>
CC: Brian McBride <bwm@hplb.hpl.hp.com>, RDFCore Working Group <w3c-rdfcore-wg@w3.org>

Jan Grant wrote:

> On Wed, 15 Jan 2003, Brian McBride wrote:
>>At 12:03 14/01/2003 +0000, Jan Grant wrote:
>>>5.4.1 rdfs:seeAlso
>>>You carefully don't say much here, which is good. However, I think this
>>>raises an issue which we should address (even if it's to punt) before or
>>>as part of LC:
>>>        If a resource is named by something that looks like a URI,
>>>        then what expectations can we have about that? If we (through
>>>        some process) dereference that URI, what can we expect to
>>>        see? Ie, is there any expectation (and if so, when) that
>>>        the use of a web address to name something means that we
>>>        can get a description of the named thing by dereferencing that
>>>        address? Or does the web address name the description
>>>        itself?
>>We are going nowhere near that.  Way outside our charter.
> Look at the second sentence of the primer abstract. "[RDF] is
> particularly intended for representing metadata about Web resources,
> such as the title, author, and modification date of a Web page,
> copyright and licensing information about a Web document, or the
> availability schedule for some shared resource."
> BUT throughout all our LCC documents, we repeatedly say that, as far as
> RDF is concerned, there is nothing apart from an accidental relationship
> between a URIref used to denote a resource in RDF and what the web
> considers to be named (or addressed) by that URIref. That is, that RDF
> is agnostic about any such relationship.

Technically, it's not what "the web" considers to be named by the 
URIref, it's what the "owner" of the URIref considers to be named by it. 
  Also, there isn't really a problem when the "owner's" interpretation 
of a URIref as far as RDF is concerned ("it identifies my home page") is 
the same as the (HTTP)web's interpretation of that URIref when you plug 
it into a browser ("it identifies a web page"), right?  It's just the 
case when the URIref is "overloaded" that creates the issue.

> Yet many of our examples and text gives the lie to this. It's clear also
> that WG members seem to think that there's more going on. Paraphrasing
> DanC from a recent telecon: "that [URIref used to name a test case]
> 404's, that's no good, that must be fixed." Yet _nothing_ in the RDF
> documents we've produced supports DanC's position on this. In fact,
> Appendix A of the primer explicitly shoots it down.

I don't know that the Primer is all that explicit about shooting it 
down.  The Primer (in Section 2.3) points out that when a URIref is 
overloaded like this, it creates some ambiguity, and (in Appendix A) 
points out that although this is a convention that is sometimes used, 
RDF (per se) doesn't *assume* this convention.

Certainly I agree that the link between RDF (and OWL, and ...) and the 
original Web (the one consisting of resources that can be retrieved if 
they have http URIrefs) is really important, and needs to be thoroughly 
worked out.  However, I think we've done our job if we point out the 
issue (Concepts has some text on this too).  I don't see this as an 
abdication of responsibility:  we haven't been given the responsibility 
to deal with this, and there may be ways of doing so that we haven't 
thought of yet, so I don't think we ought to be seen to be biasing the 
future direction.  I seem to recall Tim Bray, among others, not being 
overly disturbed about this situation.  Again calling on my memory, I 
believe he thinks additional descriptive information *about* the URIref 
as being a way to handle this, and I think he has a point.  This could 
be considered an issue of the "role" the URIref was playing, and roles 
could be described in RDF.

> OK, you might rule this outside our charter. But if RDF forms the bottom
> layer of the semantic _web_, where does the responsibility for answering
> this lie? At some higher level?
> It seems that in RDF in the wild, sometimes a URIref-labelled resource
> is used to denote a thing that you can get a description about using
> that name as a web address. Sometimes it denotes the description itself.
> And sometimes it denotes something else entirely. But there's no
> mechanism or machinery to support this, and the issue is rarely even
> mentioned.
> If it's not RDFCore's job, then it's certainly a TAG job, and I would
> hope that this issue can be raised as a matter of priority. There's a
> tech plenary coming up soon - maybe there?
> Please consider this a last call comment (in advance). We currently
> don't stay silent on this, we instead say "it's not our job". That
> answer doesn't suffice - it needs to identify _whose_ job it is to
> provide an answer on this.

I agree that "it's not our job" doesn't suffice as an *answer* (and as 
I've said above, I agree with you about the importance of this), but it 
is in fact the  truth.  It's also not our job to designate whose 
responsibility it is, and in a sense it would be misleading for us to do 
so.  What you might consider doing as a thought-experiment is thinking 
about what text you would like to see in RDF documents that fully 
resolves this issue to your satisfaction, and then thinking about 
whether the rest of the W3C would think it an appropriate action of the 
RDF Core WG to appear to commit the W3C to those things in its 
specifications.  Alternatively, if you can come up with text that at 
least identifies the issue more clearly than what we currently say, we 
could certainly consider inserting it in appropriate documents during 
Last Call.

One man's opinion.


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875
Received on Wednesday, 15 January 2003 07:27:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC