W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2002

RE: [xml-dev] RDF for unstructured databases, RDF for axiomatic

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 21 Nov 2002 17:24:54 +0000
Message-Id: <5.1.0.14.0.20021121165617.07b76af0@0-mail-1.hpl.hp.com>
To: "Shelley Powers" <shelleyp@burningbird.net>, "pat hayes" <phayes@ai.uwf.edu>, Frank Manola <fmanola@mitre.org>
Cc: "Jonathan Borden" <jonathan@openhealth.org>, <www-rdf-comments@w3.org>

At 09:39 21/11/2002 -0600, Shelley Powers wrote:

>Point blank -- by including containers and reification as defined in the set
>of working drafts, the WG is saying that these constructs are supported by
>the group, and will continue to be supported by the W3C into the future with
>only enhancements, rather than destructive modifications. In other words,
>these constructs are fully defined and approved.

Containers are.  We believe they have weaknesses and may be supplanted in 
the future, but for now they are defined.  Use them.

Reification.  We have made a judgement call.  We have kept the vocabulary 
but have been unable to give it much formal meaning.  We have published a 
bunch of working drafts with this in and no one has been complaining much.

But if you think it would be better bite the bullet and remove it, then 
just say so.  The WG will listen to feedback it receives.

[...]


>Again -- you should say upfront, the purpose of this document and intended
>audience -- it is not for a "general technical audience". It is for a
>specialized audience, with specialized interests. And if people don't share
>this specialized interest, or don't have the necessary background, you make
>them feel inadequate and stupid. I'm not making this up -- I had someone who
>is very smart and intelligent and well known in the industry say this.

We certainly don't want to do that.

Should we assume that a "general technical audience" has enough mathematics 
to be able to read the model theory document?  I guess it kinda depends on 
your definition of the term.

Maybe rather than using such terms, you are suggesting there ought to be a 
(Oh, I can't resist the term, Pat please don't think this is pejorative) 
health warning on the model theory doc indicating what level of 
mathematical understanding it requires.  Maybe:

[[
This document culminates in a formal mathematical specification of the 
semantics of RDF and RDF Schema using a technique called model theory.  Its 
early sections include an introduction to the mathematics used later in the 
document.  These section are intended to make the document accessible to 
those who are comfortable with basic mathematical techniques such as set 
theory but have not met model theory before.  Some readers may prefer to 
read instead the concepts doc [@@] and the schema doc[@@] which cover the 
same material in less mathematical terms.
]]

Out of interest Shelley, if you were to look at just at Appendix A - do you 
personally find that more approachable?


>No document should ever make it's intended audience "feel stupid". If you
>clarify the purpose of the semantics document, you can at least make a
>person know that they don't need to understand this document, in order to
>work with RDF. That this document is for the ontology working group and is a
>RDF working group tool.

You sound angry - do you mean to?  Would a health warning help?  Is there a 
better way?


> > But I think there will be folks who find the mathematical
> > approach a little
> > offputting.  That is why the other specs are there, the concepts document
> > and the schema document.  They are intended to say mostly the
> > same things,
> > but in precise, but less mathematical terms.  The primer should be
> > understandable by anyone, and should be all that many will need to read.
> >
>
>I find the primer to be fairly clear. And I'm partial to the concepts
>document.

I hope Frank sees this.  Frank has worked very hard on the primer and taken 
some stick for his approach.  Having a professional writer say good things 
about it is good.


>Again, though, if this document is for a general audience, then you may want
>to consider use of certain terms such as entailment. You give an example,
>and you talk about it, but you don't define it.

Good input.  Frank?


>I as a programmer, not a semantician or a researcher, or someone who dabbles
>in AI and KM in my spare time will look at your section on entailment and
>say, "Do they mean equality? If so, why don't they say equality? Why are
>they using this term called 'entailment'?"

They mean implies.
[...]


>If the team cannot support something, and will not remain silent on this,
>then to leave the constructs in will just generate argument after argument
>after argument in the future. And aren't we tired of these?

Speaking for myself, yes.


>Why do I think they should be deprecated? Because they introduce an element
>of processing into a data model -- Bag, Seq, and Alt do imply processing.
>They can be replaced by typed nodes, so don't add anything other than this
>processing semantics (though I know Pat hates me using that term -- sorry
>but it is processing, and semantics is meaning). Worse, though, is this
>inconsistency between what you're releasing as a spec, and what the team
>members are saying out in the world.

Who has been saying what.  My take on this is (from a drafted suggestion to 
clarify this in schema)

[[
Three different kinds of container are defined. Whilst the formal semantics 
of all three classes of container are identical; they are ordered 
sequences, different classes may be used to indicate further information to 
a human reader. An rdf:Bag is used to indicate that the order of members of 
the container is not significant. An rdf:Seq is used to indicate that the 
order of the members of the container is significant. An rdf:Alt container 
is used to indicate that typical processing of the container will be to 
select one of the members.
]]

is is very rough and needs tidying up but does that make sense to 
you?  Does that differ from what other folks are saying?

>If you can't back something, and can't stay silent on same, then deprecate
>it. However, if the majority of you feel that the construct is good, and
>sound, and only a few of you don't like it, then document the disagreements,
>but reassure the audience that the construct is not going away. Not only
>will the construct be clearly defined, but the WG's opinions, and the W3C
>official stand on same will be, also.
>
>Is this necessary for all specs? Not at all, but it sure seems to be needed
>for this spec.
>
>The working group is delivering more than cleaned up and clarified
>documents -- it's also providing a W3C official stand on how a specification
>will be implemented and used. Any fudging on this will leave us worse off
>than before.

No there I must disagree with you.  We do not say anything about how to 
implement.  We define no processing model.  I agree with you it would be 
good to have one, but that is just one of the many things we have not 
done.  We define the syntax of the (ok 2) language, we provide a 
specification of the semantics of the language and a guide on how to write 
the things you want to say in it.  But that is all we do.  And it has 
bl**dy well exhausted me working with these guys to get that far.

Brian
Received on Thursday, 21 November 2002 12:23:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:31 GMT