W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: resources and URIs

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 18 Jul 2003 18:03:36 +0300
Message-ID: <001801c34d3d$c9e46c40$770ca20a@NOE.Nokia.com>
To: "ext Michael Mealling" <michael@neonym.net>
Cc: "Tim Berners-Lee" <timbl@w3.org>, "pat hayes" <phayes@ihmc.us>, <www-tag@w3.org>, "Pat Hayes" <phayes@ai.uwf.edu>

----- Original Message ----- 
From: "ext Michael Mealling" <michael@neonym.net>

> > ...
> > perhaps a useful ontology for resources could be something
> > along the lines of the following:
> > 
> > --
> > 
> > webarch:WebResource 
> >    rdfs:subClassOf rdf:Resource;
> >    rdfs:comment "A resource which is denoted by a URI which
> >                  is intended to be resolvable via HTTP to a
> >                  representation." .

> So a WebResource is only available via HTTP? So none of my applications
> are part of the web?

Well, OK, for the moment, we could say something
a bit more general such as

       rdfs:subClassOf rdf:Resource;
       rdfs:comment "A resource which is denoted by a URI which
                     is intended to be Web resolvable 
                     to a representation." .

It then remains to be defined what "Web resolvable" means,
which will likely specify one or more specific protocols.

Does the above work better for you?

> > A resource, in general, need not be denoted by any URI, nor
> > need be referred to in any semantic web statement.
> And I think that's what's confusing. I would really prefer it if
> something not be a 'Resource' if it didn't have a URI. Call it an
> 'object' or a 'flobitz' or something else. The definition of 'on the
> Web' really isn't all that useful.

Well, RFC 2396 uses the term Resource, which is anything that
can be named (my interpretation: denoted) by a URI. I don't see 
how the Web architecture specification can change that.

Rather, you can use the specific term WebResource to specify
the particular class of things that fall into the domain of
the web.

Your attempts to define "Resource" more strictly than 2396
seems like stealing the term and preventing the SW layers
from using it according to its broader definition.

> > The web architecture is thus concerned with WebResources and 
> > Representations (among other things).
> > 
> > The semantic web architecture is concerned with 
> > SemanticWebResources and SemanticWebStatements (among
> > other things).
> This I'm starting to like. Fix that dependency on 'http' and I could go
> for it....

Perhaps the above redefinition of WebResource does
that for you.


> > Particular agents may only be concerned with Web Resources,
> > or only with Semantic Web Resources, or only the intersection
> > of Web Resources and Semantic Web Resources. But they're
> > all resources.
> You're fine until you get to that last unqualified 'resource' at the end
> of the sentence. Where is the definition of that word taken from?
> Hopefully not 2396.....

Yes. (though possibly no, since there are some issues
regarding what 2396 actually means by 'resource')

Let's say that I take the definition of resource from
the interpretation of 2396 adopted by RDF Core.

Note that's not the same as a definition by RDF Core,
but simply what RDF Core has understood 2396 to mean
by 'resource' as reflected in the RDF specs.

> > One can then extend the above ontology to include predicates
> > for relating resources to their representations, synonymous
> > denotations of resources by multiple URIs, etc. (here's
> > where the Semantic Web extends/augments the Web, making
> > explicit the semantics of web behavior in relation to the
> > universe of resources).
> Cleanly defining all of that would be useful....

I very much agree. It would certainly go along way to 
avoiding future, endless interations of this discussion ;-)

> > <other examples snipped>
> I'm fine with using OWL to cleanly delineate the relationships between
> different definitions of 'resource'. I'd just want to make sure we get
> the relationships right. The dependency on HTTP is one that really bugs
> me...

Hopefully the more general definition above, without explicit
dependency on HTTP, is more satisfactory for you.


Received on Friday, 18 July 2003 11:03:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC