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.

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.

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

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

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?

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?

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.

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.

Does this make sense?

Shelley

Received on Thursday, 21 November 2002 10:44:05 UTC