[
Lists Home |
Date Index |
Thread Index
]
I've also cc'd the RDF comments mailing list as this definitely reflects
comments about current working drafts.
>
> What Ive tried to do in the RDF semantics doc is to at least mention
> everything, even if only to say 'we don't give this any meaning',
> which is the case eg for rdf:value. In some cases - reification and
> containers and now collections as well - we say that formally there
> is no (or very little) semantics, but that there is a kind of
> recommended-informal-interpretation, and that 'semantic extensions'
> are allowed to impose meanings on these terms which conform to these
> outlines. This is a bit of a weaselly having-ones-cake-and-eating-it
> kind of position, I agree, but it seemed the best available
> compromise. The problem we had was that our charter is to clarify and
> make precise an existing language which had a flawed spec but was
> already in use, so we couldn't just write on a blank slate. In all
> these cases we *could* have given these things a 'tight' meaning, but
> there were options, and every option would have burned the fingers of
> some existing case users. So we didn't want to say that using other
> meanings violates the spec.. On the other hand, we do want them to be
> taken as strong recommendations for good future practice. So saying
> that extensions MAY assume these, is like saying: if your extension
> DOESNT assume something consistent with this, and it breaks when
> plugged into some RDF written by someone who DOES assume it, then its
> YOUR FAULT.
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.
Your charter does not preclude you using the deprecation marker. From the
HTML document:
"A deprecated element or attribute is one that has been outdated by newer
constructs. Deprecated elements are defined in the reference manual in
appropriate locations, but are clearly marked as deprecated. Deprecated
elements may become obsolete in future versions of HTML. User agents should
continue to support deprecated elements for reasons of backward
compatibility.
Definitions of elements and attributes clearly indicate which are
deprecated."
By using deprecated, you clearly state which constructs are not going to be
supported in the future, while still ensuring backwards compatibility. This
would have allowed you to signal those constructs in RDF that you all
consider to be 'broken', while replacing them with ones the group would
prefer -- but to still ensure backwards compatibility.
There is nothing in your charter that precludes the use of deprecation.
<snip>
>
> In the case of reification, we did have to take a stance to some
> extent and our recommended interpretation is actually at odds with
> some extant uses. We went with the perceived majority rather than the
> theoretically more elegant option. In this case, not incorporating
> this into the formal semantics was a decision made partly because to
> have done so would have enormously complicated the entire thing, and
> we decided that it wasn't worth the extra complexity. (Jonathan, I'm
> referring to the need to talk about document tokens rather than
> abstract triples.)
>
Personally, I believe elegance belongs on the dance floor, and I want
effective, clean, consistent, and reliable constructs in my specs. If the
preferred approach met this criteria, then you should go with the better
approach and again, use deprecation to mark those aspects that aren't
supported. If this would leave conflicting interpretations of the same
graphic (or RDF/XML), then this is a case where you should obsolete the
'bad' uses, and promote the good ones and we take the lumps. Especially for
reification -- it's use has been sparse, compared to containers.
> > >
> >
> >Then the specification should say "This is crap -- don't use it."
>
> If I had had my druthers, this is what I would have written. But I am
> merely a lowly semantician, a mathematical drudge, and I obey my
> masters. Tote that bar, lift that bale...
>
Actually, what we're saying about the semantics document applies to all of
the documents.
> > > >...Personally, I believe that neither
> >> > construct is discussed further in the semantics document
> >> because each is,
> >> in
> >> > a way, a re-interpretation of already defined aspects of
> the RDF model.
> >>
> >> ??? Huh ??? The RDF Semantics document *is* the definition of the RDF
> > > "model". It was written specifically to fix ambiguities which
> >> have resulted
> >> from interpretations such as yours of the RDF M&S (i.e. old version).
> >>
<snip>
>
> >Processing -- each item in a sequence is related to every other
> item in this
> >way -- that is what is known in the computer world as 'processing'
> >information. As in, when you see this tool makers, this is how
> you process
> >it.
>
> Sure, but be careful about the phrase 'processing semantics', which
> is often used to convey the idea or claim that the *meaning* of the
> language is to be found in the processing done to the expressions of
> the language. This is true, or at least plausible, when its a
> programming language, particularly an interpreted programming
> language; but its not a good way to think about an
> assertional/descriptive language like RDF. Of course, RDF gets
> processed (hopefully) but the point is that in this case, the
> processing should follow the meaning, in the sense that it should
> constitute valid inferences, rather than defining the meaning.
>
But Pat, there is a processing semantic attached to containers. That aspect
of containers that represents a data structure -- a descriptive structure if
you will -- a grouping of related items has no implied processing other than
the relationship. However, when you give a Bag, Seq, and Alt type, you're
attaching processing semantics to the construct. This is no different then
attaching conditional processing semantics to 'if' in most programming
language.
You may say that no processing is implied, but that's not what we read. This
adds to confusion.
<snip>
> >
> >Actually, it has a lot of problems. It was created by a group of smart,
> >wonderful people who really care about making RDF work BUT who have a
> >difficult time understanding that not all of us have PhDs in
> linguistics and
> >mathematics. Or Philosophy.
>
> Well, I did try to write the semantics doc so that it didn't
> presuppose having technical qualifications in logic or philosophy,
> and explained its ideas as it goes along. If it was written for a
> technical/mathematical audience it would probably be about 1/3 the
> length and have hardly any English words in it. The Webont WG OWL
> semantics are written more in this style, you might find the contrast
> amusing.
>
I'm actually not as concerned about the semantics document as I am the
others. I think the biggest problem with the documents in difficulty
understanding who your audience is. Is it the tools developers? The language
semantician? The RDF end user? Rather than break across functional lines,
perhaps the documents should have broken along audience lines. (Or did they?
Is the RDF Primer the document for the end user?)
> >They add references to containers in the primer and the syntax,
> but in the
> >semantics document, add this statement basically forcing interpretation
> >about 'containers' back on the user.
>
> Have you read the newest draft? It tries to give a better exposition
> of RDF container. The key point is that RDF *describes* containers
> rather than *constructing* them. Then the rather sparse semantics
> makes more sense, I think: its not saying that the containers
> themselves are 'thin' or ambiguous; its just that RDF doesn't say a
> whole lot about them.
>
Enough to be possibly damange the credibility of the release.
> >In this case, they definitely
> >re-introduced ambiguity. Why? Because a lot of them don't like
> containers,
> >they wanted to get rid of containers, they think containers are
> redundant.
>
> 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.
> >Worse, containers add processing semantics to what is a data
> model. I happen
> >to agree with them -- containers are redundant. They were, at one point,
> >actually pulled from RDF. Or at least there was a WG note for this at one
> >point.
>
> Yes, that might have been one option. Another would have been to
> redesign the containers from the ground up; we could have done a much
> more elegant and formally tight version. But the old container
> vocabulary would then be deprecated, and we felt this was needlessly
> drastic, particularly as we were adding collections to overcome many
> of the problems. Making something retrospectively illegal is not an
> action to be taken lightly.
>
As stated previously, deprecation is good and doesn't necessarily hurt your
existing tool and RDF users. W3C has used deprecation with HTML, and it has
a much wider user base. Deprecation would not have violated your charter.
As for not doing it lightly -- leaving in vaguely defined semantic
constructs strikes me as a bit more serious. Wouldn't you think?
> >However, there are a lot of tools and uses of containers in the world (ie
> >RSS 1.0). Too many people like and use containers, so they didn't pull
> >them -- they just tried to sweep them under the rug.
>
> Well, we tried to say enough about them to make them useful without
> saying so much as to cause many users' code to be broken. Its
> necessarily a compromise. We also added collections, which were
> introduced by the DAML joint committee to overcome the failings of
> rdf containers.
>
> >They pulled them from
> >the abstract model (where they really don't belong) but left them in the
> >implementation model, within the RDF/XML zyntax.
>
> There is no distinction between abstract and implementation models.
> These things are in the language but have a 'weak' semantics.
> Applications can assume a stronger semantics, but at their own risk,
> like Swiss drivers.
>
> Pat Hayes
Shelley
|
