- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Wed, 5 Mar 2003 08:39:11 -0500
- 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: site:creation-date site:last-modification-date site:backup-date 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. Jonathan
Received on Wednesday, 5 March 2003 08:39:32 UTC