RE: N3 rule for proposed Resource-Description header

> From: Williams, Stuart (HP Labs, Bristol)
>
> > From: Booth, David (HP Software - Boston)
> > [ . . . ]
> > Hmm, it hadn't occurred to me that one might want a
> > Resource-Description header on a 303 response.  But, yes, I
> > can see that that could be useful also, and could be treated
> > as indicating ancillary assertions just as for a 200
> > response.
>
> Well... I could just as easily see them as being (if we must
> use the terms) "core" assertions. I do not see the reasoned
> basis on which a distinction (at least for header based
> references) is made.

The basis for distinction is purely this: which assertions *must* be accepted by a statement author wishing to use the URI to denote its associated resource?    In other words, if the intent is to extend DanC's rule at
http://www.w3.org/2006/04/irw65/urisym
"Use of a URI of the form. doc#id implies agreement to information published at doc", to URIs yielding 200 responses with Resource-Description headers, exactly what information should use of the URI imply agreement to?

> I could, maybe, accept an ancillary
> stance for descriptions that are some number of links away
> (possibly just >1) from a response message (headers or body)
> for the requested resource. But descriptions referenced
> directly from the response surely carry equal weight from the
> point of view of being what the authority for the name meant to say.

Right, but if the referenced descriptions were considered *core* assertions, then how would you deal with the problem described in lines 347-360 at
http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/att-0003/rules.n3.txt
Wouldn't it be rather unreasonable to tell people that they couldn't make statements about a document unless they agreed with the document's metadata?

>
> [BTW: i haven't checked, but it occurred to me that the rules
> that you have been drafting don't check that the formula
> taken as declarations have anything to say about the declared
> resource;

You're correct in observing this.  This is explained at
http://dbooth.org/2007/uri-decl/20080403.htm#unrelated-core
[[
Furthermore, although the intent of a URI declaration is to supply core assertions that uniquely identify the denoted resource, there is no requirement that the core assertions be limited to assertions about that resource.  For example, if the URI declaration for http://dbooth.org/2007/moon/ had contained an additional core assertion stating "Elvis is king", users would have been required to accept this assertion or forego use of the URI.  This may seem odd, but there are two reasons for it.  One is that some statements that are not directly about the moon may still represent assumptions that are important to the proper understanding and use of the URI.  The other is that I do not know of any practical and objective way to judge whether an assertion is relevant or not, because its relevance may depend on the minter's intent.  I would be interested in ideas for other approaches that would limit the assertions to those that are relevant to the denoted resource.
]]

> also are they singular or conjunctive?]

I don't know what you mean.  Can you explain?

>
> > I could see this as being particularly useful in
> > support of suggested practice P4:
> > http://dbooth.org/2007/uri-decl/#p4
> > "A URI declaration page should provide links to suggested
> > ancillary assertions about the resources whose URIs are
> > declared by that page."
>
> I remain unconvinced about the necessity or utility of the
> core/ancillary distinction.

See
http://dbooth.org/2007/uri-decl/20080403.htm#why
Does that help?

And here is an excerpt from a document that has not yet been published:
[[
. . . when a Semantic Web application reads a statement involving a previously unknown URI, and it needs to know more about that URI, its task is to locate the URI definition that the statement author intended.  [When a reliable follow-your-nose definition is available], under the URI declarations approach (rule C-UD-1) the process is simple: the application uses the URI's follow-your-nose definition.  But under the competing definitions approach (rule C-CD-1) the application faces two problems:

   1. Until there is a standard mechanism for specifying an alternate URI definition (to be used instead of any f-y-n definition), the application cannot, without assistance, be assured of getting the right URI definition, hence violating the self-describing Web [12] principle.
   2. Alternate URI definitions cause URI collision, as described above.

Of course, problem 1 will go away if such a mechanism is standardized.  But problem 2 will not.  In short, in the normal case, any architectural rule that permits statement authors using the same URI to base their statements on different URI definitions leads to harmful URI collision.

Furthermore, even if the problem of URI collision is viewed as a necessary harm en route to the higher goal of community-accepted URI definitions, the notion of a "community-accepted definition" is tenuous, because different communities might "standardize" the definition of a URI differently.  That would be bad, because the Semantic Web should enable serendipitous combinations of data across communities.  In fact, it may be difficult to even ascertain whether a community-accepted definition had reached the globally accepted stage.  Furthermore, as the number of parties increases, the difficulty of reaching agreement increases.  In such situations it seems much more likely that the eventual outcome would not be a single, community-accepted definition, but a community-accepted definition for each community, thus perpetuating URI collision indefinitely.
]]
Does that help?

>
> > If the URI owner has already published a URI declaration and
> > doesn't want to change it to add links to suggested ancillary
> > assertions, then a Resource-Description or Link header could
> > be a good way to do it.
>
> Not that I want to argue for the distinction, quite the
> opposite in fact (see Pat and John Cowan elsewhere on "There
> are no such things as Unicorns" :-)) a Link: or
> Resource-Description: would be a good way to associate "core"
> assertion with an information resource/200 response
> particularly in cases where it is not possible to add them to
> the corresponding resource representation.

But then how would you deal with the problem I mentioned above? (Described in lines 347-360 at
http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/att-0003/rules.n3.txt .)

> [ . . . ]
> Trying again:
>
>       That "Link:" or "Resource-Description:" headers are
> present in the response
>       does not make for an irrefutable claim that the
> resource is an IR.
>
> which is how the para on which I was commenting came across
> to me (ie. attributing irrefutable claim to headers rather
> than response code).

Oh, okay.  Yes, I agree: it is the 200 response that irrefutably implies that the resource is an information resource -- not the presence of a Link or Resource-Description header.



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 Saturday, 5 April 2008 01:35:19 UTC