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

>  >
>>  >Pat, I understand the constraints that you all work under, but
>>  you're doing
>>  >future consumers of RDF a deservice with this approach. This has
>>  >re-introduced ambiguity. More than that, this approach makes it
>>  difficult to
>>  >determine what is or is not 'compliant' RDF.
>>
>>  Since this has been posted to www-rdf-comments, I think its only
>>  fair to ask:
>>
>>     o what is ambiguous?  Is there a test case?
>>     o Do you have test case for which it is unclear whether it is
>>  or is not
>>  'compliant'.  I don't recall us defining a notion of compliance.
>>
>
>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.

Yes, but we are careful to restrict the commitment involved. I think 
this is an important point. You seem to want us to either say, this 
is EXACTLY what the thing means, or else to toss it out. BUt I really 
don't think that is the right way for us to go in every case. We can 
instead say, these .....  are the only assumptions about this 
construct that we we are willing to commit to. We expect that future 
extensions will make stronger assumptions, and we recommend that they 
do so in a way that conforms to this description .... and do not do 
so in ways that would give them this interpretation ..... . NOw, this 
is being vague if you like, but it is also leaving room for RDF to 
grow and be extended without needing to come back and undo or 
re-write what we put into the spec. I'll give you an analogy from one 
of my other lives. When laying a poured-slab concrete foundation, its 
often a good idea to think of ways that the building *might* get 
extended in the future, and do your best to predict where the new 
electrical circuits are going to want to go, and install some empty 
conduit under the slab. Similarly for water circulation or drains. 
Its cheap to do before the concrete arrives. If nobody uses them, 
theres no serious harm done; if they aren't in exactly the right 
place, then you can make work-arounds at the ends; but if you don't 
do this and later someone does want to use them, its a hell of a lot 
of work to dig up the slab and re-pour it. RDF is more like a 
foundation than a finished building, and its got a quite a few pieces 
of empty pipe sticking up out of it.

>
>No, "Really, we don't like them much, but we're stuck because of our
>charter" will surface to cause confusion at a future time for some poor sod
>just trying to figure out what and what not to use.
>
>Is this a correct understanding?
>
>>
>>  >Your charter does not preclude you using the deprecation marker. From the
>>  >HTML document:
>>
>>  The advice we received from our W3C representative was not to deprecate.
>>
>>  [...]
>>
>>  >I'm actually not as concerned about the semantics document as I am the
>>  >other. I think the biggest problem with the documents in difficulty
>>  >understanding who your audience is.
>>
>>  My view, Pat, feel free to disagree/expand:
>>
>>  The model theory began in my mind as a technical tool to help the WG have
>>  useful discussions.  I had too much experience of long and ineffective
>>  discussion or RDF which foundered because there no precise language for
>>  discussing what RDF meant.  The formal semantics has been wonderfully
>>  useful to the WG; we may disagree about things, but is much
>>  clearer what we
>>  disagree about, and when we make a decision, what decision we have
>>  made.  It is so useful, we decided to publish.
>>
>>  So there is your first audience, the RDFCore WG.  A second audience are
>>  other WG's that are building on RDF, e.g. WEBONT.  They have
>>  people who can
>  > read the math and understand exactly what RDF does and does not mean.
>>
>
>Then this is your audience -- not a general technical audience. You should
>clarify this. Saying otherwise does everyone a disservice.

Ah, I see. I put that phrase in the semantics doc, and it did express 
my intentions; but if causes more harm than good I will take it out.

>
>>  I must pay tribute to the effort and skill that Pat has put in to
>>  extending
>>  the reach of the document to those with college level knowledge of
>>  mathematics.  Time will tell how much of this audience will reach, but it
>>  does mean that many of the WG at least can understand and use it, and I
>>  hope will extend far beyond that.
>>
>
>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.
>
>No document should ever make it's intended audience "feel stupid".

Indeed, sorry if it did that, that is a disaster. I will rewrite 
that, thanks for pointing it out.

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

It is genuinely intended to be more than just that, and it has 
already been widely read and commented on and used. But OK, 'general 
technical audience' is too vague and all-inclusive.

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

The semantics doc defines it in section 2., and it has a paragraph 
which tries to explain the concept intuitively.

>
>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'?"
>
>You can't assume a specialized vocabulary and say that a document is for a
>general technical audience.
>>  [...]
>>
>>  > >
>>  > > No, not at all. The problems run deeper. The real problem is that if
>>  > > containers are unordered (like rdf:bag) and you use an ordered set of
>>  > > selection functions on them, then you are kind of imposing an order
>>  > > on what is conceptually an unordered thing. So your description in a
>>  > > sense says *too much* about it. So if we allow RDF to make any formal
>>  > > entailments about bags, they are almost all going to be wrong, in
>>  > > fact, so we had to block them. For example suppose you say that A is
>>  > > a bag and its first item is X and its second item is Y. If you allow
>>  > > RDF to permute the items, then you can infer that Y is the first
>>  > > item. But now *both* X and Y are the first item...
>>  > > There are other problems, notably with there being no way to say that
>>  > > a container is 'closed', ie has no more elements.
>>  > >
>>  >
>>  >And that's why I don't like containers in this type of model.
>>
>>  I suggest we've done as much as we can to make the M&S definition of
>>  containers precise.  If you want to suggest we delete or deprecate them,
>>  then the thing to do is post the suggestion to RDF comments and explain
>>  why.  The WG will listen.
>>
>
>Okay, then you should deprecate them. Your own team members have said they
>don't like them. They will say this in the future. This will confuse the
>audience. Should they use them? Or not?

Well, seems to me that the clear answer is: sure, use them. But use 
them in a way that only utilizes the aspects of their meaning that 
are in the RDF spec. Don't, in particular, assume that the use of the 
three letters 'b' 'a' 'g' in 'rdf:bag' means the same as it might 
mean in Java or Lisp.

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

There should be no more arguments. We say explicitly what the 
container vocabulary means and what it does not mean, and we give 
test cases and examples in the text to illustrate both the upper and 
lower bounds on the meaning. We give an exact formal semantics in 
three different forms (including the Lbase in the appendix)  and we 
give inference rules for generating all valid consequences, rules 
which have been implemented in several pieces of working code which 
are described in the open literature and available as freeware. I 
honestly do not know how we could do more.

>
>Why do I think they should be deprecated? Because they introduce an element
>of processing into a data model

No, they don't. That is, forgive me, a misunderstanding. We do our 
best to guard against that misunderstanding in the published 
documents.

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

I don't see any inconsistency. The only thing I said that disagreed 
with the spec was that I wished we had shot rdf:Alt. But the spec 
does describe its meaning quite exactly.

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

Well, Im only in the W3C by invitation to be in the WG, so you 
shouldn't take anything I say as in any way the voice of the W3C. I 
guess Ive always assumed that the W3C stance is that its documents 
ARE what its stance is. And the RDF spec does not say how (an) RDF 
(engine) should be implemented, which in my view is entirely proper, 
since its not a programming language.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Thursday, 21 November 2002 16:45:01 UTC