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: Shelley Powers <shelleyp@burningbird.net>
Date: Thu, 21 Nov 2002 12:34:31 -0600
To: "Brian McBride" <bwm@hplb.hpl.hp.com>, "pat hayes" <phayes@ai.uwf.edu>, "Frank Manola" <fmanola@mitre.org>
Cc: "Jonathan Borden" <jonathan@openhealth.org>, <www-rdf-comments@w3.org>
Message-ID: <AOEKLHGMHIHGNIBEDMNMIEGCDFAA.shelleyp@burningbird.net>

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

No, I don't have a problem. Others do. My biggest concern is me telling my
book audience something about reification that isn't what the WG intended,
or that won't be supported at some arbitrary point in the future.

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

If I'm not the targeted audience, Brian, it wouldn't matter whether I was
more "comfortable" with this or not.

If the semantics document is for the ontology group and as a discussion
point for the RDF WG, it doesn't really matter if I'm comfortable with it,
does it?

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

Not angry. Not at all, though I did face on angry people last week trying to
defend the RDF/XML.

Health warning is about the worst thing you can do. "Excuse me, but you have
to have college level math to understand this".

But then, if you're like me and have spent the last 20 years creating
applications rather than doing research, I may be a tad rusty with my
college level math.

No, what you should do put in what you told me:

"This document was created to help the RDF WG understand the semantics....
It should be viewable by a general technology audience with some experience
in.... However, it isn't essential to work with RDF/XML or to understand the
underlying RDF concepts. However, if you're .... you should make the effort
to read and understand this document."


Now, what is wrong with that?

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

Frank, you done good. If you remove reification or containers, I'll sic the
entire weblogging community on to you.

(joking. just joking)

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

Shelley puts gun to head and shoots self.

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


And I know you all have worked your butts off here (can I say 'butt' in a
W3C mailing list?) I respect that. But I'm literally between a rock and a
hard place -- between the average Joe wanting to use RDF for a door factory
in Wisconsin, and those in white coats who see RDF as the cornerstone for
some grand, esoteric semantic web. And, in some way, I have to define what
is the "Practical" aspects of RDF.

Sorry, Brian. I'll end these discussions. It's up to me to muddle through
somehow.

Shelley
Received on Thursday, 21 November 2002 13:35:43 GMT

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