Re: discovering site metadata

At 12:37 AM 2002-02-08 , Mark Nottingham wrote:
>
>Well, I wrote up an I-D about this and everything, but after some
>experimentation with Apache and IIS, it looks like supporting this
>is... difficult.
>
>Instead, what about just making a request to the most generic
>resource on the server (i.e., /) and requesting the appropriate
>content-type? So,
>
>GET / HTTP/1.1
>Host: www.example.org
>Accept: application/p3p-prf+xml
>
>GET / HTTP/1.1
>Host: www.example.com
>Accept: text/robots
>
>406 Not Acceptable (or a response with a mismatching media type)
>would indicate that it isn't available (in which case the legacy
>well-known location could be polled).
>
>(I chose OPTIONS * because that was an explicit request about the
>*entire* server. After being lightly steeped in REST for a while, I
>think that requests to / can make statements about all of the
>subresources of / authoritatively. What I do want to avoid, however,
>is having more than one entry point - it would be bad if you had to
>request /images/ to see what metadata applied to subresources of it,
>for example).
>

You are getting warm.

Think HEAD request against the root URL associated with the domain name.  

The root URL for a domain is the commercial best practice for the page that is the default and generic entry point for the realm proper to one "corporate author" or virtual business entity.

The HEAD request gets you metadata for that resource, be it the site or the first page on entering the site..

And the metadata captured in the HTTP headers / SOAP envelope for the launch page includes generic terms and conditions for that page such as "general properties and conventions practiced on this site."  That is not all there inline in the headers, of course, but there is a "more about me" reference that starts you down the path to wandering that patch of web.


In HTTP it could be a Context-Climate: header with URI-reference value or a details= elaborating parameter on Content-Type.  To win a truce from XML-dev it has to be very obvious that the application of the 'more' is strictly optional.  That the core methods of the object you get in this message do not depend on interpreting the referend, and can be successfully completed simply by the well-kown climate of constraints associated with the registered and well-known MIME type as identified in the Content-Type header.

QED.

As far as what you get if you follow the URL that is in the new "more about me" reference in the headers for the home page...

It may refer you elsewhere for stuff about the images, sure.  And you may get the image more metadata directly from a HEAD request issued against the URL for the images directory.  But we have lots of tools for weaving webs of information.  Think LINK, XLink, and A with rel/rev/role properties known to the metadata-walking schema.

You should neither have to descend the tree nor ascend the tree to get this information.  You should be able to get there following HyperReferences.  And the commercial best practice already gives you a 'forward' hyperlink HOME from essentially every fragment of the corpus that is the site content.  But the "more about me" reference in the headers should be populated on every page regardless.  And be context specific to that page where the service offeror has thought that through.  But the page-specfic stuff would embed a forward-motion path on to the site-generic context conditions review should that be different,

Please re-read <http://lists.w3.org/Archives/Public/uri/2001Nov/0047.html> carefully.  I know it's windy.  But the "moreAboutMe" notion is just something we need to be supporting everywhere.

Links at the foot of the page provide more about myTopic, what I'm about.  Headers provide information about me and myKind.  This should split into a) what you absolutely need to know and b) what you additionally might find useful.  I'm repeating myself.  But we need this culture instilled in SOAP and we need to retrofit it into HTTP/HTML to provide a graceful path for queries to flow from an instance of data to the notional context that goes with it.

Al


>
>
>On Thu, Dec 06, 2001 at 11:48:32PM -0600, Dan Connolly wrote:
>> On Wed, 2001-12-05 at 20:43, Mark Nottingham wrote:
>> [...]
>> > The obvious solution would be to use OPTIONS * along with an
>> > appropriate accept header (or maybe something like AcceptNS?).
>> 
>> er... not too obvious; I hadn't considered it before.
>> 
>> It's a nifty idea.
>> 
>> 
>> 
>
>-- 
>Mark Nottingham
>http://www.mnot.net/
> 
>

Received on Friday, 8 February 2002 10:40:22 UTC