Re: Issue rdfms-assertion

At 09:24 AM 11/15/01 -0600, Dan Connolly wrote:
>Brian McBride wrote:
>[...]
> > >>   http://www.w3.org/2000/03/rdf-tracking/#rdfms-assertion
>[...]
>
>Sorry, I can't let this one get swept under the rug...
>
> > I'm really suggesting that the model theory is all we are going to say 
> about the
> > meaning of RDF.  What the law chooses to do about folks who put RDF 
> statements
> > on web pages is a matter for lawyers and politicians, not for us.
>
>On the contrary: the RDF Core WG is in the W3C Technology
>and Society domain for a reason: to make the connection
>between bits on the wire and social obligations.
>
>There is some crazy laywer running around trying to encourage
>web site owners to screw up their P3P policy files in such
>a way as to be able to disclaim responsibility for their content.
>[P3P isn't quite written in RDF, but it was supposed to
>be, and should be, in a future revision, I hope].
>I suggest that this WG has an obligation to say that no,
>that's not consistent with the community's agreement
>about how this technology works.
>
>If you write, in RDF,
>         "This is an offer to sell widgets for $200 ea"
>ala*
>         <> a ucc:Offer;
>                 ucc:itemClass myCatalog:Widget;
>                 ucc:price [ ucc:USD [ dt:decimal "200" ]].
>
>where ucc: is bound to a "Uniform commercial code"
>schema, ratified by some 47 out of the 50 United States,
>and you serve that document via an HTTP 200 response,
>then you are in fact obliged to honor that offer just
>as if it were published in a printed catalog.
>
>The HTTP 200 bit is quite relevant... this issue has
>a lot to do with the protocol context in which RDF is used.
>As such, I originally considered this issue part of
>   http://www.w3.org/2000/03/rdf-tracking/#mime-types-for-rdf-docs
>but it was split out.

OK, maybe this is the key part.  RDF alone does not have a "protocol 
context".  So simply waving the above piece of RDF at a lawyer isn't going 
to get them to agree to anything.

I think the entry point to this would have to be the protocol context, or 
the way in which an exchange of RDF data is embedded in or linked to a 
social interaction.  To make this work, I think it's clear that the 
"meaning" of RDF must be well-defined, and to that extent I think that the 
model theory DOES satisfy the issue, per Brian's proposal.

But I think that RDF alone cannot satisfy the criterion you post:
[[[
The RDF specs should define a
semantics so that an RDF statement on the web is interpreted as an assertion
of that statement such that its author would be responsible in law as if it
had been published in, say, a newspaper.
]]]

because:

(a) RDF does not define the semantics of the vocabulary used (ucc:Offer, 
ucc:price, etc.)

(b) RDF+vocabulary alone cannot establish the intent to make and/or accept 
the offer.  (e.g. two RDF programmers in email:  Q: what would an offer of 
widgets for $200 apiece look like?  A:  like this...)  For this, I think we 
need an adequate protocol context.

I think our difficulty with this issue is that most of the details are 
beyond the ken of this group to adequately discuss, hence adequately 
address.  I think the best that we can do towards this is create a 
framework that states unambiguously under what certain circumstances some 
abstract graph fragment can be claimed to be asserted.  Other parties, 
other places can deal with the issues of defining vocabularies, protocols 
and legal frameworks under which the graph fragment can be regarded as 
incurring a legal liability.  (From past discussions with Rigo Wennig I 
understand this is the approach adopted for P3P.)

Hence I agree with Brian's proposal to close the issue because I think the 
model theory does as much as we can.

#g
--


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/

Received on Thursday, 15 November 2001 12:16:10 UTC