RE: N3 rule for proposed Resource-Description header

Hello David,

> Given the discussion on the TAG list about "Uniform access to
> descriptions" and the confusion/discussion on our last AWWSW
> call about what can be inferred from a 200 response, and what
> can be said about a Web document,

FWIW I don't think I detected much in the way of confusion.

> I added a rule to the
> attached rules.n3 for inferring a set of ancillary assertions
> from a Resource-Description header.   A test case test7.n3 is
> also included.

>From your pov would you regard any description referenced from a response header (eg. Resource-Description; Link <target>,rel="meta" and variants...)
as ancillary, or just specifically references made by Resource-Description?

FWIW: I mostly prefer the Link header (at least in the way it is used here - it has a broader syntax in its original defn and one presumes other utility associated with that larger syntax) provided the rel value can be grounded in URI space (ideally *be* a URIReference) because it then allows an arbitrary relation to be made between subject resource and target. Use of different rel values could then distinguish say WSDL descriptions, from POWDER descriptions from, Dublin Core bibliographic data, or a Handles/DOI style 'library card'... (mostly for the pragmatic reason of not necessarily having to visit all the descriptions to find the one you are most interested in).

Just skim http://dbooth.org/2007/uri-decl/20080327.htm at trying to dig a little more into the objective distinctions between what you call "ancillary assertions" and what you call "core assertions" http://dbooth.org/2007/uri-decl/20080327.htm#authoritative I find:

"A URI declaration is authoritative only in defining the association between the declared URI and a particular resource.  The declaration creates a social expectation that other parties making use of that URI will use it to denote that same resource."

Wrt to the first sentence, I thought that there was reasonable agreement that what you call a URI declaration cannot possibly do that. AFAICT that is the nub of Pat's critique and you have said "URI declarations do not try to solve that problem." [1].

[1] http://www.w3.org/mid/184112FE564ADF4F8F9C3FA01AE50009E254DB11E9@G1W0486.americas.hpqcorp.net

Wrt to the second sentence, I don't see how such social expectation is created by the presense/existence of any URI declaration or by the existence of such a concept. From my pov, it is a social expectation arising from the architecture of the web; from the use of URI's as refering names.

Ok... I've looked a little more at the rules between lines 230 and 373 from which it seems to me that "URI declaration" status wrt to some URI "u" is afforded to:

1) formula arising from retrivals based on the racine of "u" in the case where "u" is a hash URI. (lines 254-267)
2) formula arising from retrivals that follow a 303 redirection from "u" (lines 269-296)
3) a synthesied formula asserted for InformationResources in the case of a 200 response
   (saying solely that there resource is an information resource) (lines 298-325)
4) formula arising from retrivals that follow an rdfs:isDefinedBy reference (lines 327-345)#

"Ancillary assertion" status wrt some URI "u" is afforded to:
5) formula arising from retrivals that follow a reference made "Resource-Description" header associated with "u".

It seems to me that is an arbitrary choice. I see little difference in the weight/significance that one would apply to formula arising in 2 or 5 above. After all arranging for the corresponding responses from URI "u" requires similar levels of endoresement of the referennce by the publisher of <u> - I don't see why one is deemed more or less a declaration than the other.

If there were any razor that I might apply to separate "core" from "ancillary" it would be whether there was a direct path (possibly a single step direct path) between "u" and the description. ie. it is deemed "core" or a URI Declaration, if i can get to it in one step from the referenced resource (ie a direct link in the response headers or body); "ancillary" assertions are less directly accessible findable (ie. more steps or not at all) from "u".

However, overall, I think this is part of a more general trust and provenance issue - with respect to what assertions/descriptions about a thing a given agent is willing to accept.

> In rules.n3:
>
>  - Lines 132-135 define the hasResourceDescription property,
> which indicates that a particular HTTP response contains a
> Resource-Description header.
>
>  - Lines 248-252 define a hasAncillaryAssertions property,
> which indicates that a URI has a particular set of ancillary
> assertions available, which the application may or may not
> choose to assert, as explained in
> http://dbooth.org/2007/uri-decl/#ancillary .
> The reason the Resource-Description assertions must be
> architecturally considered ancillary assertion rather than
> core assertions is explained in lines 347-360:
> [[
> 347. # an HTTP Resource-Description header.  Note that if URI u
> 348. # is dereferenced to obtain a Response containing such a
> 349. # header, and the header points to a metadata document containing
> 350. # assertions, then those assertions must NOT be interpreted
> 351. # as core assertions for u's declaration.  Rather,
> 352. # they must be treated as ancillary assertions, as described in
> 353. # http://dbooth.org/2007/uri-decl/#ancillary .
> 354. # This is necessary to enable someone to use u to make
> 355. # a statement about its denoted document, such as:
> 356. #    <u> :hasRating :awful .
> 357. # without implying agreement with the assertions in the
> 358. # metadata document, which after all could contain a
> 359. # statement such as:
> 360. #    <u> :hasRating :excellent .
> ]]

I think ones ability to say things about a set of assertions at <u> is entirely independent of whether assertions at <u> are regarded as "core" or "ancillary".

So, I'm sorry... but I don't get the point that is being made.

>  - Lines 346-371 define the inference rule for asserting
> hasAncillaryAssertions from an HTTP Response containing a
> Resource-Description header.
>
>  - Lines 298-325 define the inference rule for inferring a
> URI declaration from an HTTP 200 response (per the
> httpRange-14 decision), as before.  Note that a URI
> declaration for a Web document ?r denoted by a URI ?u is very simple:
> [[
> 318.            ?r a awww:InformationResource .
> 319.            ?r uri:hasURI ?u .
> ]]
> I'm not 100% sure that the uri:hasURI assertion on line 319
> should be treated as one of the core assertions -- perhaps it
> should be an ancillary assertion -- but I think it is
> harmless to include it as a core assertion, since it is
> irrefutable given the successful 200 response that triggered the rule.
>
> In test7.n3:
>
>  - I used the example of describing the relationship between
> http://www.w3.org/TR/rdf-mt/ and
> http://www.w3.org/TR/2003/WD-rdf-mt-20030123/ i.e., that the
> dated URI denotes a version of the (time-varying) "document"
> denoted by the undated URI.
>
>  - Lines 57-70 assume that the Resource-Description header
> specifies a metadata URI,
> http://dbooth.org/2008/httpinf/metadata7.n3 .  The metadata
> document contains the assertion:
> [[
> <http://www.w3.org/TR/rdf-mt/> dcterms:hasVersion
>         <http://www.w3.org/TR/2003/WD-rdf-mt-20030123/> .
> ]]
> which, by the new inference rule, becomes an available
> ancillary assertion for http://www.w3.org/TR/rdf-mt/ .
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Opinions expressed herein are those of the author and do not
> represent the official views of HP unless explicitly stated otherwise.

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 3 April 2008 10:22:10 UTC