RE: N3 rule for proposed Resource-Description header

> From: Williams, Stuart (HP Labs, Bristol)
>
> 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?

*All* descriptions referenced (by URI) from the response header must be treated as ancillary assertions.  Under the architectural assumption that use of a URI to denote its resource implies agreement with the core assertions of that URI's declaration, then for a document uDoc at URI u with a linked description dDoc at URI d, if the assertions dDoc were considered core assertions, then use of u to denote uDoc would imply agreement with those assertions.  This would prevent others from using u to denote uDoc if they don't agree with the assertions in dDoc.

>
> 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).

The only reason I chose Resource-Description over Link was because I understood it better.  I don't understand what 'rel="meta"' means, because "meta" isn't a URI, so I can't look up what it's supposed to mean.  :^)

>
> 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/184112FE564ADF4F8F9C3FA01AE50009E254DB11
> E9@G1W0486.americas.hpqcorp.net

As described in more length at
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0140.html
the association between a URI and a resource is a two-step mapping:

  Step 1: A mapping from the URI to a set of core assertions that are intended to characterize the resource; then

  Step 2: An interpretation of those core assertions as identifying the actual resource.

Step 2 is outside the control of Semantic Web architecture.  It is inherently ambiguous and is left for philosophers to ponder.  URI declarations do not try to address the step 2 problem.  Fortunately, step 1 is what matters to Semantic Web applications, and this is what URI declarations address.

Pat Hayes (quite reasonably) misunderstood the intent of URI declarations as addressing both steps in this association.  This misunderstanding was caused because my prose was sloppy in a way that I had not previously realized would cause misunderstanding.  I've just now tweaked the prose and added more explanation to this part:
http://dbooth.org/2007/uri-decl/20080403.htm#two-step
and this part:
http://dbooth.org/2007/uri-decl/20080403.htm#authoritative
I hope those changes are improvement.  Please let me know if you (or anyone) think they still need more clarification.

>
> 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.

Yes, but the Web architecture delegates the authority to the URI owner:
http://www.w3.org/TR/webarch/#uri-assignment
[[
URI allocation is the process of associating a URI with a resource. Allocation can be performed both by resource owners and by other parties. It is important to avoid URI collision (§2.2.1).
]]

And BTW, the term "by other parties" in the above should be clarified as "their delegates".

>
> 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)

Yes.

> 2) formula arising from retrivals that follow a 303
> redirection from "u" (lines 269-296)

Yes.

> 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)

Yes.

> 4) formula arising from retrivals that follow an
> rdfs:isDefinedBy reference (lines 327-345)#

Yes, however, that rule is only intended as an escape hatch for dealing with broken or erroneous follow-your-nose URI definitions, as in that case the URI declarations approach degrades to the "competing definitions" approach.

>
> "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".

Yes.  Any other assertions involving <u> would also be ancillary assertions, but that is the only rule I provided for finding some.

>
> 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.

Yes, but the critical difference is that in case 2 no other objective information is architecturally available to a SWeb app about the denoted resource, and thus it is harmless to view the URI-owner-endorsed assertions as core assertions -- and in fact, beneficial.  In contrast, in case 5, a SWeb app at least knows irrefutably that the denoted resource is an awww:InformationResource -- regardless of what else might also be true about it -- and thus someone may want to make statements about it as such without being forced to agree with any other assertions that the URI owner wanted to make about it, which after all could be something disagreeable such as:

        <u> :hasRating :excellent .

>
> 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".

So if a URI u does a 303 redirect to uA, which in turn does a 302 redirect to uB, then it sounds like you would consider the assertions at uB to be ancillary rather than core assertions for u.  Can you explain why?  It seems perfectly harmless to me for uA to forward to uB.  The chain of authority/delegation is still established.  Once there is one level of indirection I don't see the harm of permitting more.  However, I'm not sure the inference rules are currently factored in the best way possible wrt indirection.

>
> 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.

Yes, but viewing it merely as the more general trust and provenance issue is throwing the baby out with the bath.  The general issue of trust and provenance will still be present for ancillary assertions -- there's no way around that.  But there is benefit in architecturally distinguishing between core assertions and ancillary assertions, as I've tried to explain at
http://dbooth.org/2007/uri-decl/20080403.htm#why
and
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0084.html
As the latter explains, without the notion of mandatory core assertions, a SWeb app "must either incur the cost of finding and correctly deciding between competing URI
definitions -- a judgement call that it is unlikely to be able to fully automate -- or risk misinterpreting the statement".

>
> > 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.

The "metadata document" is a *different* document -- not u.  To clarify, assume there is some document d at URI u, and a GET returns a response containing a URI uMeta for document dMeta, which contains the statement:

        <u> :hasRating :excellent .

Given those conditions, I now wish to use u to make a statement about d (because u denotes d).  I happen to think that d is an awful document, so I wish to write:

        <u> :hasRating :awful .

But if the assertions in dMeta were considered core assertions for u's declaration, then I could not make this statement without implying all of u's core assertions, *including* the one that says:

        <u> :hasRating :excellent .

which I clearly do *not* wish to say.  Make sense?



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.

Received on Thursday, 3 April 2008 16:42:07 UTC