[SCL] Some questions for SCL and RDF

[Tanel Tammet]

Hi,

After brief thinking about SCL and RDF relations
some questions came up. I'd appreciate a lot
if you can shed some light on the issue described below.

Let us take a file in RDF or OWL. Pat has a nice
semantics for this (both the mainstream one and
the one in http://www.coginst.uwf.edu/~phayes/OWL2LBASE.html).
I have also seen alternative semantics (possibly
partial) along the same lines.

The machinery used in these semantics is
explicit encoding. RDF and OWL formulas are
not translated "directly" to FOL. Instead,
a number of predicates like type, class,
relation, symmetric etc are used.

These predicates are associated with a finite
list of axioms.

Now, if you take a naive understanding of an
RDF or Owl formula, you would not use the
predicates class, type, etc directly.

If "man" is a class and "human" is a class
and one is a subclass of another you'd like
to say "forall x . man(x) implies human(x)".

The standard semantics machinery does not
take this route. Now, I do understand the
encoding machinery, which is fairly
classical (we could always just use one
predicate "apply" and encode any intuitive
predicate as a constant, for example).

For example, combinatory logic is built up like
the RDF/OWL semantics machinery.

For the SCL-RDF connection I'd be much
happier with a more direct conversion
machinery, where you would translate the
fact that man is a subclass human like
"forall x . man(x) implies human(x)".

There are several reasons for this:

- such a translation would be naturally
combinable with ordinary, non-RDF/non-OWL FOL.

- such a translation is much much better for
automated theorem proving. Before attempting
to answer queries from RDF/OWL I'd surely do
whatever possible to convert the meanings
directly, without using the extra axioms.

Any encoding layers are typically a real
horror for a prover. You do want to eliminate
the encoding layers as much as possible.

Also, observe that a formula F and an encoded formula enc(F)
are typically not equivalent, since the signatures
of F and enc(F) are different (analogy to Skolemisation:
Skolemised formula sk(F) is not logically equivalent
to a non-Skolemised formula F, although their
consistencies are equivalent: one is consistent
iff another one is).

For the practical purposes of combining SCL
and RDF/OWL it would be IMHO nice to have
a translation machinery RDF/OWL->FOL which
does not rely on axioms being added to
the output of the translation.

Has anybody worked on such a translation
(IMHO a necessity for FOL theorem proving in
the Owl context)?

Even if it may be hard for the general case,
surely we can translate large subsets of RDF/OWL
in the direct manner.

Regards,
        Tanel Tammet












You'd
instead u



Tanel Tammet wrote:
> Hi,
> 
> Thanks, Murray, for the most useful comments. I think
> several things you point out should be put into the draft.
> 
> However, before submitting the third draft I'll wait for
> more comments, and most importantly, real SCL abstract
> syntax (and possibly, the human-readable syntax one as
> well). SCL-in-XML has to follow what the SCL main draft
> says, not vice versa.
> 
> Since you asked about some issues and I felt unsure
> about some things you suggested, here come
> comments to some of your questions/comments (and nothing more).
> 
> 
> Murray Altheim wrote:
> 
>> Attached are my comments on the second draft. Primarily, I think
>> before any reasonable discussion can approach these decisions
>> on logic logically, there needs to be an agreed-upon set of
>> application requirements upon which each decision can be judged.
> 
> 
> Waiting for the SCL draft itself.
> 
> I tend to thing that we cannot realistically agree upon
> a set of application reqirements. For example, when looking
> at you large list of goals/requirements in your html version
> of XCL, I thought about how abstract-and-generally-good
> they are: that is, it is utterly nontrivial to agree
> upon the priorities there and then put the priorities to
> practice.
> 
> IMHO it is easier to work on the spec drafts and see if they
> correspond to various ideas of people about what are the
> crucial issues.
> 
> As for my own priorities (which surely not everybody agrees to
> or understands in the same way), they'd be something like that,
> in the rough order of importance:
> 
> - non-ambiguous and clear meanings
> - ease of implementation (incl ease of understanding)
> - easy extendability
> 
> It would be pointless to argue, say, about these three
> "requirements": they are too vague, too intertwined, too
> ambiguous. Requirements like these are IMHO understandable
> privately, but very very hard for a group of people to tract
> or to be used as metrics.
> 
> 
>> But what about extensions? What if someone wants meet(i,j)? How
>> will a processor know its correct arity?
> 
> 
> In the tivial sense the arity of predicates and functions is arbitrary:
> it is only important that the arity of "meet" is the same in
> all its occurrences in the whole formula. This is easy to check
> after or while parsing.
> 
> In the nontrivial sense Pat and other people argue strongly for
> the SCL to incorporate non-fixed-arity constructions (translatable
> to fixed arity). But this is another issue and I'd wait for
> the SCL draft to see in which layer and how it is presented.
> 
>>> - Murray: shorten some, but no all, tag names,  for example <quant> 
>>> instead of <quantifier>    
>>>  Comment by Tanel: confusing to have some tag names as full
>>>  names in English, some as shortened. Better to keep full
>>>  names consistently. Since XML is very verbose anyway,
>>>  micro-optimisations such as shortening the tag names are useless.
>>
>>
>>
>> Depends on the application. I've been hearing arguments from John
>> and others about verbosity being an issue. Is it or isn't it? Saving
>> half the number of characters used in element type names over a
>> document of 300,000 elements is significant. The shortening leaves
>> names that are still unambiguous. Are most CL documents expected
>> to be large or small? 
> 
> 
> What I claimed here is that micro-optimisations are pointless.
> A few characters less here and there does not help. For the
> compressed version of a file it anyway won't matter whether
> an often-occurring tag name is a few characters shorter or longer.
> 
>>> - Murray: use XLINK namespace to refer to parts of other docs
>>>
>>>  Comment by Tanel: unclear why we need to to make other namespaces
>>>  obligatory. Rather, let us introduce a parameter href (as
>>>  xlink:href or just href in html) for referencing. This is subject
>>>  to discussion.
>>
>>
>>
>> If you use the XML namespace you must declare it. You can't use 
>> xlink:href
>> without declaring what "xlink" refers to. If you use "href" (or "foo",
>> for that matter) application developers will have to write their own
>> code for linking rather than using XLink libraries. The whole purpose
>> of XLink wasn't simply to provide a linking syntax, it was to provide
>> a whole methodology (and by extension, software libraries) for linking
>> in XML. Using "href" will gain you none of that.
> 
> 
> Why I am worried about other namespaces like XLINK. Suppose we say
> that one should use the XLINK machinery for a highly important
> purpose of including parts of other texts.
> 
> Then, in order to write inclusions in your SCL-in-XML (and also
> in order to implement the software) you need to read through the
> XLINK specs. I did that after you suggested XLINK. The spec is
> big and nontrivial to understand: a bit intimidating if you simply
> want to include text.
> 
> I'd say that for a person basically understanding FOL it
> would be much easier to understand the SCL specs than
> XLINK specs.
> 
> I am very worried about unnecessary complexities.
> 
> Writing a highly complex spec (or taking existing
> complex specs quietly into your own as a requirement/assumption)
> is a sure path to irrelevance.
> 
> Perhaps we could use parts of XLINK and put the relevant explanations 
> from the XLINK specs into the SCL-in-XML specs directly, so that people 
> would not have to read and understand all the XLINK specs?
> 
> To summarise: your arguments for XLINK are sound, but we should
> definitely avoid the complexities they seem to introduce.
> I do not know how to reconciliate these two opposing
> viewpoints nicely.
> 
>>>  NB! Observe we could use XLINK namespace instead of putting these
>>>  into SCL-in-XML namespace. In the current draft we DO NOT use XLINK
>>>  namespace, just to simplify matters. This may be changed.
>>
>>
>>
>> Are you proposing that your "Simple CL" (what I've called XCL Level 1)
>> incorporate linking features? Or is this left to a future version?
> 
> 
> I do not know. Look at the argumentation above. More feedback
> and materials necessary before we can make sensible decisions here.
> 
> I have put the linking machinery into draft version 2 to create
> material for discussion and further thinking about this important
> issue which has to be tackled sooner or later.
> 
>> I'm curious as to why you feel the need to namespace prefix SCL but
>> not HTML. I'd do the opposite, since you can declare a default XML
>> namespace (unprefixed) and have all non-SCL markup prefixed. I'd have 
>> done the opposite. It saves space, is a lot easier to read,
>> and the namespace prefixes are unnecessary. Your example didn't
>> include the declaration for "scl:" so to compare fairly:
>>
>>   <scl:quantifier xmlns:scl="http://scl_namespace_uri/"
>>                   scl:name="forall" scl:variable="x"
>>                   scl:id="foo">
>>    <scl:predicate scl:name="r">                  <scl:term scl:name="x"/>
>>     <scl:include scl:href="#bar">
>>    <scl:term/>
>>   <scl:quantifier/>
>>   or
>>
>>   <quantifier xmlns="http://scl_namespace_uri/"
>>               name="forall" variable="x"
>>               id="foo">
>>    <predicate name="r">                  <term name="x"/>
>>     <include href="#bar">
>>    <term/>
>>   <quantifier/>
>>
>> They mean exactly the same thing to an XML processor.
> 
> 
> Sure. I have avoided the default namespace usage in
> the example (ie used namespace explicitly everywhere)
> just to point out clearly that these and these
> names are in the SCL-in-XML namespace.
> 
> A visual clue for reading the spec draft.
> 
>> You might want to mention the implications of IDs and the ID
>> namespace, vs. values within the 'name' attribute.
> 
> 
> I am not too fond of the attribute called "name"
> I am using everywhere in the examples. It looks
> a bit ambiguous for a human reader.
> 
> Would be nice if somebody comes up with a better
> alternative name for this parameter than "name".
> 
> 
>>> What is not prohibited
>>> -----------------------
>>> SCL does not prohibit using additional tags, parameters and parameter
>>> values inside SCL text structures. 
>>
>>
>>
>> Why not?  Are you defining an interchange syntax or simply providing
>> a playground for vendors and developers?
> 
> 
> It is very very important that people can extend the core language.
> 
> Look at the actual, practical necessities in the TPTP library
> of thousands of FOL problems. The TPTP author/maintainer Geoff
> will tell you any day that it is absolutely necessary to add
> various metainformation to formulas.
> 
> Now, these metainformation snippets should not be put into core
> SCL. There is no way we can decide which should be in and which
> should be out. People will build their language layers above
> core SCL if SCL is to be used. If you cannot build your own
> language layers, then you cannot realistically use SCL.
> 
> Language layers are OK if we keep the layer structure
> modular.
> 
>>> In particular, users can invent their own parameters to mark formulas 
>>> as belonging to different parts of the knowledge
>>> base (for example: axioms for arihtmetic, theory of lists, knowledge 
>>> of a particular person, a query, etc).
>>
>>
>>
>> Are there any rules for this, or do we expect to receive an SCL
>> document and have to figure out what it means by hand? Will 
>> non-standard SCL documents be labeled differently than ones that
>> conform to the standard?
> 
> 
> See above.
> 
>> The one thing I think necessary in order to determine the answers
>> to design questions (and the first thing I did) is to define a
>> set of requirements for SCL and have everyone agree to those 
>> requirements. Then it's a matter of determining whether a specific
>> option meets or fails the requirements. 
> 
> 
> As I said in the early parts of this letter, this is IMHO
> unobtainable in practice, if taken formally.
> 
> The people working on this do have informal requirements
> in their heads, these change, and eventually some consensus
> is reached, where the informal requirements are taken
> into account.
> 
>> As it is now, you simply
>> say you don't think a decision fits your understanding of the
>> goals and toss it aside. Other people's requirements may be quite
>> different than yours.
> 
> 
> That is why the language we create is a collective creation,
> not mine, yours, or anybody elses. We need discussions
> like this one here.
> 
> Regards,
>          Tanel
> 
> 
> 
> _______________________________________________
> SCL mailing list
> SCL at philebus.tamu.edu
> http://philebus.tamu.edu/mailman/listinfo/scl
>