W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

RE: referendum on httpRange-14 (was RE: "information resource")

From: <Patrick.Stickler@nokia.com>
Date: Wed, 20 Oct 2004 09:37:09 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADD4C@trebe051.ntc.nokia.com>
To: <sandro@w3.org>
Cc: <Norman.Walsh@Sun.COM>, <www-tag@w3.org>



> -----Original Message-----
> From: sandro@roke.hawke.org [mailto:sandro@roke.hawke.org]On Behalf Of
> ext Sandro Hawke
> Sent: 19 October, 2004 17:06
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: Norman.Walsh@Sun.COM; www-tag@w3.org
> Subject: Re: referendum on httpRange-14 (was RE: "information 
> resource")
> 
> 
> 
> 
> > > Seriously, I'm writing this while procrastinating about 
> answering this
> > > for myself in Ontaria.  I need a tab on which to display 
> information
> > > about any resource for which dereference worked, and I'm 
> not sure what
> > > users are going to want to see on that tab.  I'm also not 
> sure what to
> > > call it (ie what the class name is), but I'm leaning towards=20
> > > "Document".
> > 
> > I think the only safe class name would be "Resource".
> 
> I think it's at least "Web Resource" -- a member of the class of
> things which are identified by at least one dereferenceable URI.

Yes, I agree. I made this response too quickly, and later, as I'm
sure you noticed, mentioned that Web Resource would be applicable.

Hoping, of course, that we end up with such a term in AWWW...

> Maybe there's a better name for that class....   Things identified
> only by mailto:, tag:, and urn: URIs wont be in this class.  (I have
> no plans to include a URN resolver.)

This illustrates why I don't think there's much utility in explicitly
classifying a resource as a "web resource" -- because it reflects
accessibility of representations of that resource, i.e. it reflects
the behavior of the web in terms of that resource, but does not 
reflect any characteristic inherent in the resource itself. And since
membership in that class of resources is transient, even if one 
encounters a statement "ex:foo rdf:type ex:WebResource." that doesn't
mean that when they go to access a representation they won't get
a 404 response -- since that statement could have been asserted quite
some time ago, and in the meantime, all representations of that
resource were removed.

While it's useful to be able to talk about the class of web resources,
I'm not so sure it's particularly useful to talk about a *specific*
resource being a web resource, except for very low level tasks
at specific points in time.

Maybe I'm missing a key use case where having a persistent RDF
statement asserting membership in that class is truly useful. 
But I can't think of one.

???

> It's odd to present it as a property of the thing, though, since it's
> pretty far removed from its intrinsic properties.  Maybe I should
> present it as a property of the URI (a particular kind of character
> string).  But that's also weird.....

I think what's needed is a solid use case. That should clarify
the best way to express whatever is needing to be captured here.

The problem, of course, with trying to define properties of the URI
is that you *can't* make any statements about the URI. E.g. the
following is invalid RDF:

   "http://example.com/foo"^^xsd:anyURI rdf:type <ex:ResolvableURI> .

since, of course, literals can't be subjects. I tried to get
typed literals allowed as subjects, since (a) they were new constructs,
so it was not as drastic a change as allowing *any* literal to be
a subject, and (b) they had very specific semantics, but no go.

Of course, there is my proposed val: URI scheme, which predated
the typed literal construct and reflects a typed literal as a URI:

   val:(DATATYPE_URI)LEXICAL_FORM

But that's far less optimal than just allowing literals as subjects
(which should be fine, since they all have consistent interpretation).

Oh well... maybe in RDF 2.0 ;-)

Patrick
Received on Wednesday, 20 October 2004 06:37:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:43 UTC