Re: Action 299 - removing sorts

> 
> kifer@cs.sunysb.edu (Michael Kifer) writes:
> > 
> > > 
> > > > http://www.w3.org/2005/rules/wg/track/actions/299 has been completed.  Part
> > > > of the title of this action says: "handle datatypes as in RDF."  This was
> > > > *not* what was resolved at the F2F and was put in there by mistake (I
> > > > hope).  Certainly, I would not have agreed to such an action, since I do
> > > > not know what this might mean in logic.
> > > 
> > > As I recall, by that point of the meeting we were in something of a
> > > hurry, and people were talking over each other, so I guess I can
> > > understand how you missed this.  In general, there should be a pause and
> > > people should double check on IRC to make sure their action is recorded
> > > in a way they are comfortable with.  It sounds like there was a process
> > > error in not making sure we did that.
> > > 
> > > There was not a clerical error in drafting that action, however -- I
> > > proposed that wording to match my understanding of group consensus.
> > > 
> > > Specifically, I heard people saying we still needed some kind of "sort"
> > > thing for data values, and general murmurs that what RDF has is fine.
> > > 
> > > As I understand it, RDF Semantics just formalizes the notion in XML
> > > Schema that a string like "3" or "2001-01-01" is a lexical
> > > representation of some individual in a "value space" (the number three,
> > > or the day Jan 1, 2001), and that a datatype URI identifies a mapping
> > > from these lexical representations to values.
> > 
> > 
> > I am not sure what does it have to do with RDF, but it all you meant "data
> > types" then yes, it is there.
> 
> Well, I think different people have different ideas about what "data
> types" might mean.   So I included the phrase "as in RDF" to try to
> clarify that.

Well, this is like "clarifying" one murky thing with another.
Hardly can possibly help.


> Hopefully that means we're fine.  I haven't reviewed your changes yet.
> 
> > > The actual spec is:
> > >       http://www.w3.org/TR/rdf-mt/#dtype_interp
> > > 
> > > > Other than that, the main changes are in 
> > > > http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions
> > > > http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions (to a much
> > > > lesser extent).
> > > > 
> > > > Although sorts have been removed, signatures remain. I do not know how
> > > > to ensure extensibility without signatures. When you read it, you might
> > > > notice the term "signature name". This has nothing to do with "sort names".
> > > > Just so that you'd know :-)
> > > 
> > > I can't picture what you mean here.   Can you give me an example of how
> > > signatures help with extensibility?
> > 
> > 
> > I should ask you a counter-question: can you specify a series of dialects
> > (let's say, just two) such that the bottom will be the horn core, as we
> > agreed,
> 
> (As a side note, for people just joining in here, the Core==Horn
> assumption has been called into question, was discussed last week, and
> is on the agenda for being revoked tomorrow.   That doesn't matter for
> this discussion -- we can just use Horn as one dialect.)
> 
> > and at the top will be something like HiLog or even common logic?
> > Do not use signatures, but start with the FOL sharp distinction between the
> > different kinds of symbols.
> 
> Can I use something we might call "HiHorn", which is just Horn with
> "higher-order" syntax as in HiLog?  (I'd rather avoid all the other
> LP/Prolog stuff that's in HiLog.)

Call it a foobar. But the design should be such that it does not preclude
extensions.


> > Then outline a general way of converting from BNF to XML and then prove that
> > for every spec S in the horn core FH(S) = FC(S), where FH is the function
> > that converts the horn core to XML and FC is the same function for the
> > Common Logic/HiLog dialect.
> 
> I don't understand your construction here, sorry.  What is a spec S?

By spec (= specification) I meant some set of formulas that one wants to
ship somewhere through RIF.

> Maybe give me an example or two, or use some other words to describe
> it.  Is a "spec" a "rule language defition (syntax + semantics)" or a
> "ruleset serialization (document)", or ... what?

You need to show that your design is extensible. This implies the above
property. Basically, if you have a ruleset in a lower dialect, its XML
should be valid in higher dialect. Its logic (= syntax and semantics)
should also be valid in a higher dialect "as is" without any transformations.

> 
> > After thinking about this same problem for a few weeks after the F2F I came
> > to the conclusion that we need to keep signatures.
> 
> You may well be right -- I have no idea -- but I need to understand how
> & why.
> 
> > In fact, signatures
> > was the original proposal for extensibility. Sorts came in only after
> > people started talking about data types. We still have sorts * 0.5, by the way,
> > without calling them such. We just call them XML data types. We just do not
> > have variables over these sorts (so it is just 1/2 of that concept).
> 
> Yes -- my understanding is that we took sorts out because we had no
> common understanding of them.  It's not that there was anything wrong
> with them; we just couldn't even agree on what "they" were.

Unlike many things about the semweb, sorts were formally defined, and
the definition was very simple and standard.  If we could not "agree on
what they were" it could be a problem with the presentation and with the
fact that we were trying to accomplish too much at that f2f.

> In general,
> in the future, I hope we're much more careful to stop and switch to
> classroom mode, and tutor everyone until they really understand the
> subject (and therefore know whether the terminology is being used as
> they expect), before we adopt anything.  (I should probably take this
> advice seriously myself.)

Good advice :-)


	cheers
	  --michael

Received on Monday, 16 July 2007 20:13:19 UTC