W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

Re: URI: Name or Network Location?

From: Jon Hanna <jon@hackcraft.net>
Date: Thu, 19 Feb 2004 10:33:08 +0000
Message-ID: <1077186788.403490e47ca35@>
To: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>

> | Maybe I want to make statements about the webpage:
> |
> | <ex:Webpage rdf:about="http://www.hbo.com/Sopranos">
> |    <ex:homepageOf rdf:resource="http://www.hbo.com/Sopranos"/>
> |    <ada:accessibilityRating>Good</ada:accessibilityRating>
> | </ex:Webpage>
> |
> | So "http://www.hbo.com/Sopranos" is both an ex:TelevisionSeries and an
> | ex:Webpage about itself.  That doesn't seem right.
> You have to assign a different URI to the webpage.
> http://www.hbo.com/Sopranos/home, say. This can solve to the same
> representation as the URI for the series; you can use an HTTP
> Content-Location header when serving http://www.hbo.com/Sopranos
> (causing relative URIs to work right).

I was thinking about the same question last night, musing over whether
could be turned into something genuinely useful.

One thing that occurred to me is that the need to describe both the webpage and
the resource it represents is probably going to be relatively small. Surely an
implication in the whole REST concept is that the resource is more important
than the representation, hence how often do we care what the title of a HTML
page is - more to the point how often do we care  what the title of a HTML page
is and lack the ability to find /html:html/html:head/html:title (unless the
page is ill-formed but then why would we expect well-formed RDF?).

I can see the question of "what are the titles of all the pages (HTML or
otherwise) which are used to represent this resource?" as being useful, but I
don't think that will always require that each page can be identified in and of
itself. Hence I think a blank node for the resource which is the representation
of named resource may be adequate for many cases.

Jon Hanna
*Thought provoking quote goes here*
Received on Thursday, 19 February 2004 05:33:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:47 UTC