RE: N3 rule for proposed Resource-Description header

Hello David,

> -----Original Message-----
> From: Booth, David (HP Software - Boston)
> Sent: 05 April 2008 02:33
> To: Williams, Stuart (HP Labs, Bristol); public-awwsw@w3.org
> Subject: 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?

There are two steps: 1) finding something that says something about doc#id and 2) some determination as to whether any, some (eg. only those about doc#id) or all (all the assertions in the description: including those that it imports (imports closure)?; and all those that arise from descriptions of the terms used in that closure?...);

        <u> rdfs:isDefinedBy <dDoc> .
        <dDoc> ex:hasRating <veryBroken> .

What should be my disposition wrt to the statements in <dDoc>?

My willingness to accept <dDoc> is based no only on how I came by the reference to <dDoc>, but also on what <dDoc> has to say - whether accepting it is going to render my kb inconsistent and if so the origin of the assertions that I've already accepted with which those from <dDoc> interact unfavorably (as I might want to reconsider my acceptance of them).

BTW wrt with the rules at lines 327-244 for URI decls arising from rdfs:isDefinedBy, there is no restriction on where the rdfs:isDefinedBy assertion is made - it could being made anywhere on the web, in multiple places with multiple different ?rdef binding.

> > 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-0
> 003/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?

But that is precisely what I think you are saying wrt to "core assertions" that in using a term I *MUST* necessarily agree with the core assertions. Why is that any more reasonable?

> > [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?

Only that you potentially have multiple rule firings all of which potentially assert URI decls for a given resource. If that occurs, is it an error? Do they all apply (conjuctive)? Do they overwrite each other - most recent wins?

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

Don't know yet... thinking...

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

Well.. what I think that you are saying is that in order for me to use a given URI u, in a document there is an obligation on me to ensure that I concur with a set of "core" assertions associated with u by some means. A sort of viral set of assertions (abit like the way GPL works)...

The rdfs:isDefinedBy form make such agreement very difficult (at least given the current ruleset) I think - because the origin if such statements is unconstrained [admittedly you can probably improve the rules to be more specific].

For me the invariant of the web is that intentionally users of a given URI are speaking of the same thing, even if what they have to say is in conflict. But the Mark Baker example from Dan's paper that you mention above is a good one - Mark's own assertions about <http://www.markbaker.ca> and the implict URI Decl arising from the rules (triggered by a 200 response code) are in conflict.

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

ie.
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'm quite happy to hold the minter of a URI accountable of assertions that they make about the URI which they minted - and provide you with the means to find either via 303/Location:, or Link: or Resource-Description: or whatever. However, there is nothing that restricts the target of any of these to be sets of statements made by the minter of the original URI. The most one can say is that whatever those assertions are, the minter of the URI thought that they would be useful at least at the time the URI was minted/deployed - otherwise why reference them at all by whatever means.

With care the minter of can contain the locus of those references. Under those circumstances I see no reason why the means by which the reference is made makes any difference to the standing of what is being said - in effect, to use the notion of 'core' assertions - the minter of the URI is using some other URI as a target (for a 303/Location:, Link: or Resource-Description:) and as a consequence is equally committed those what those targets say (and what their "core assertion" have to say of them... and so forth).

[...]

> 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 Monday, 7 April 2008 17:26:26 UTC