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

Re: siteData-36: strawman + httpRange-14 [ "Resource-Type:" ]

From: Jonathan Borden <jonathan@openhealth.org>
Date: Wed, 5 Mar 2003 08:39:11 -0500
Message-ID: <012301c2e31c$9dda3cf0$b6f5d3ce@L565>
To: "Tim Bray" <tbray@textuality.com>, "Sandro Hawke" <sandro@w3.org>
Cc: <www-tag@w3.org>

Sandro Hawke wrote:

> I like the background discussion and the mechanism.  I see one little
> flaw near the end:

The proposal make sense. I don't agree that there is a flaw. I also agree
that there is a more general solution that entirely encompasses this issue.
see comments below.

> > Of course, this leads inevitably to the question of what is a useful
> > representation for a site.  The kinds of stuff that could go there could
> > include robots info, language info, favicon.ico equivalent, RSS info,
> > p3p info, etc etc etc.  Unlike the RDDL issues we've been discussing, I
> > see little requirement for human readability, so this feels like a
> > natural for a small (but extensible) RDF vocabulary, who cares if it's
> > ugly.  The RDF assertions would mostly have as their subject the URI "",
> > which works well in this case.  -Tim
> But if you do that, then you can't distinguish between assertions
> about the site and assertions about the site information document.
> For instance, the site might have been created on one day and this
> site-information RDF document might have been created on another.  Is
> the triple
>    <> dc:date "2003-02-27"
> saying that the site was created today or that the meta-site
> information page was created today?

That might depend on the semantics of the property "dc:date". At face value
the "dc:date" property is being applied to "<>" so I'd say that it is a
property of the site itself.

On the other hand I see no need to apply the property "dc:date" whenever we
intend to use a date -- a point of RDF datatyping is that a property's
_datatype_ is a function of the property, so that we might have:


etc. each of which are dates. Now suppose we restrict the _domain_ of the
property to apply to sites i.e.

site:last-modification-date rdfs:domain :site .

well then it becomes quite simple, anytime we see:

<> site:last-modification-date "2003-03-05" .

we _can infer_ that <> is a :site!

> You could solve this using TimBL's foo#bar style, with sites being
> named so that, for instance, http://www.w3.org/site#member would
> identify the "W3C Member-Only Site", "http://www.w3.org/site#all"
> might identify the "Overall Site", ... and this still leaves
> "http://www.w3.org/site" to identify the document prividing
> information about one or more sites.  I suppose one or more of those
> sites might contain that meta-information document.

this complexity is not needed see above.

> It's interesting to note that "Site" here, as I think you've described
> it, is an RDF type or RDFS/OWL class.  Each resource is either part of
> the site or it's not, and the ones which are part of the site have
> certain common characteristics.  So one might call the HTTP header
> "Resource-Type", in nice parallel to "Content-Type".  In this case we
> would certainly expect people to define their own Resource-Types and
> make available information about them on the web (ie in these site
> meta-data information documents).   This is of course much broader
> that the normal notion of web sites, which are entirely disjoint
> classes.

I generally agree. "Site" is one type of resource, perhaps its special
enough to get its own HTTP header (?) but why not just (example HTTP
response headers):

Resource-Type: http://example.org/siteOntology#Site
Resource-Description: http://example.org/site.rdf

would solve this problem, as well as [httpRange-14] in a general fashion.

Received on Wednesday, 5 March 2003 08:39:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:58 UTC