[SCL] Some notes for SCL-for-RDF concrete syntax
Tanel Tammet
tammet at staff.ttu.ee
Mon May 12 15:33:07 CDT 2003
Hi,
Attached please find a few notes, ideas, questions
and examples for the SCL-for-RDF concrete syntax
which we should perhaps write in not too far future.
Regards,
Tanel Tammet
-------------- next part --------------
SCL for RDF concrete syntax: a few ideas, suggestions, questions
----------------------------------------------------------------
T.Tammet
12. May 2003
This letter is NOT a draft of a spec, not even an early one.
Rather, I'll attempt to present some rough and simplistic ideas
about yet-another XML-based concrete syntax for SCL, this time targeted
at fitting the RDF way of thinking.
Pat has been suggesting to write such a concrete syntax.
The previous SCL-in-XML syntax is not written with a
goal to fit the RDF style. The current points are,
in contrary, aimed at RDF.
When I mention "RDF" in the following I have actually both RDF,
RDFS and parts of OWL in mind.
NB! Please look at these notes just as notes and ideas and questions,
NOT as a suggestion for implementation.
Notes on the goal
-----------------
We want to:
- allow a situation where we get a set of RDF formulas R and
a set of SCL formulas F, and we can automatically check
whether a query Q is derivable from the union R U F.
- we want to allow RDF formulas to be
understandable among the SCL formulas.
- we would also like to augment RDF with SCL, like
OWL augments RDF.
- we would like to be able to use SCL as an alternative
to OWL in the situations where standard unrestricted
logic seems easier to use than description logics do.
- The XML syntax is not a crucial issue here:
- RDF has also a triplets syntax
- RDF and OWL semantics present a translation of RDF and OWL to FOL.
Notes on the problems
---------------------
The main problems stem from the first goal above:
We want to allow a situation where we get a set of RDF formulas R and
a set of SCL formulas F, and we can automatically check
whether a query Q is derivable from the union R U F.
Hence we need to convert R to FOL in the same, matching
way as we convert SCL to FOL.
This is not trivial, since (among other things):
- Predicates in RDF are treated similarly to
constants.
Instead of saying
"forall x (man(x) => human(X))" one would rather say
"subclass(man,human)".
- Predicates in RDF cannot have arity over 2.
One has to encode literals containing predicates with a higher arity,
like the example from the RDF primer:
address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730")
encoded as:
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" .
_:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" .
_:johnaddress exterms:Zip "01730" .
- Function symbols are not syntactically present in
RDF/OWL.
In Owl one can declare a predicate to be functional,
but there is no special function syntax.
- Objects can have different kinds:
some are named by URI-s, some are blank nodes identifiers,
some are simply strings.
Notes on the solution possibilities
-----------------------------------
- Different encodings problem:
Do not convert RDF formulas to FOL in
the way which requires posing additional
axioms.
Instead, convert RDF formulas directly to FOL,
using axioms as axiom schemas instead.
This (very vaguely) is similar to a difference
between Hilbert-style and Gentzen-style
axiomatisations.
- Arity problem:
Encode any large-arity literal "P(t1,...,tn)"
in SCL as "P(t1,tuplex(t2,...,tn))"
where x is the symbol denoting the arity of this
tuple (above here x would be n-1).
"tuple" is simply an ordinary function symbol,
used as a constructor.
This encoding can be always done, obviously,
preserving satisfiability properties of the
encoded formula.
Hence we will have just one- and two-place predicates
after the encoding.
- Function symbol problems:
Once it is declared in OWL that a predicate is functional,
encode it directly as a function symbol.
Example: let us declare that "father" is functional:
instead of axiomatising father(x,y) & father(x,z) => y=z
convert a formula like "father(x,y) => man(y)" to
"(exists x (father(x)=y)) => man(y)"
- Different kinds of objects problem:
let us use function symbols to construct types.
Specifically, knowing that "http://foo.bar" is an URI,
we should write it as "uri("http://foo.bar")" to differentiate
from simply a string with the same look "http://foo.bar",
not treated as uri.
Similarly, knowing that "abc" is an unnamed node, we should
write it as a term rdf:nodeID("abc").
Naive examples
--------------
Let us convert some RDF from RDF Primer first:
- - - - - - - - - - - - - - - - - - - - - - - -
<rdf:Description rdf:about="http://www.example.org/index.html">
<exterms:creation-date>August 16, 1999</exterms:creation-date>
<exterms:language>English</exterms:language>
<dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
</rdf:Description>
becomes
exterms:creation-date(uri("http://www.example.org/index.html"),"August 16, 1999") &
exterms:language(uri("http://www.example.org/index.html"),"English") &
dc:creator(uri("http://www.example.org/index.html"),uri("http://www.example.org/staffid/85740"))
Suppose now that we declare that exterms:creation-date is functional.
Then we would TRANSFORM the first literal above to:
equal(exterms:creation-date(uri("http://www.example.org/index.html")),"August 16, 1999")
Ie the "functional" declaration would be primarily a transformation rule,
not primarily an axiom.
Let us take a blank node example from the RDF primer:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<exterms:editor rdf:nodeID="abc"/>
</rdf:Description>
<rdf:Description rdf:nodeID="abc">
<exterms:fullName>Dave Beckett</exterms:fullName>
<exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>
</rdf:Description>
These two above would become
dc:title(uri("http://www.w3.org/TR/rdf-syntax-grammar"),"RDF/XML Syntax Specification (Revised)") &
exterms:editor(uri("http://www.w3.org/TR/rdf-syntax-grammar"), rdf:nodeID("abc")) &
exterms:fullName(rdf:nodeID("abc"),"Dave Beckett") &
exterms:homePage(rdf:nodeID("abc"),uri("http://purl.org/net/dajobe/")).
Example using "type" from the RDF primer:
<rdf:Description rdf:ID="item10245">
<rdf:type rdf:resource="http://www.example.com/terms/Tent" />
<exterms:model>Overnighter</exterms:model>
<exterms:sleeps>2</exterms:sleeps>
<exterms:weight>2.4</exterms:weight>
<exterms:packedSize>14x56</exterms:packedSize>
</rdf:Description>
would become:
"http://www.example.com/terms/Tent"(rdf:ID("item10245")) &
exterms:model(rdf:ID("item10245"),"Overnighter") etc
We will now propose some examples from SCL in RDF-fiendly syntax
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The main differences from the non-rdf-oriented SCL-in-XML:
- we write predicates and function symbols as tags, not
as "name" parameter values to tags.
- we surround constant and variable symbol occurrences either
with a special "variable" tag or an "object" tag (for constants)
unless they are already surrounded by "uri" or "node" tags.
We use a namespace with a shorthand "rdflogic" for the SCL in the
following. Assume that predicates are given in a namespace
with a shorthand "mine".
forall x,y (grandfather(father(father(x)),y) becomes:
<rdflogic:forall variable="x">
<rdflogic:forall variable="y">
<mine:grandfather>
<mine:father>
<mine:father>
<rdflogic:variable>x</rdflogic:variable>
</mine:father>
</mine:father>
<rdflogic:variable>y</rdflogic:variable>
</mine:grandfather>
</rdflogic:forall>
</rdflogic:forall>
Another example:
forall x,y,z (ancestor(x,y) & ancestor(y,z) => ancestor(x,z)).
<rdflogic:forall variable="x">
<rdflogic:forall variable="y">
<rdflogic:forall variable="z">
<rdflogic:implies>
<rdflogic:and>
<mine:ancestor>
<rdflogic:variable>x</rdflogic:variable>
<rdflogic:variable>y</rdflogic:variable>
</mine:ancestor>
<mine:ancestor>
<rdflogic:variable>y</rdflogic:variable>
<rdflogic:variable>z</rdflogic:variable>
</mine:ancestor>
</rdflogic:and>
<mine:ancestor>
<rdflogic:variable>x</rdflogic:variable>
<rdflogic:variable>z</rdflogic:variable>
</mine:ancestor>
</rdflogic:implies>
</rdflogic:forall>
</rdflogic:forall>
</rdflogic:forall>
Example with a large-arity predicate:
agerange(John,30,40)
<mine:agerange>
<rdflogic:object>John</rdflogic:object>
<rdflogic:tuple2>
<rdflogic:object>30</rdflogic:object>
<rdflogic:object>40</rdflogic:object>
</rdflogic:tuple2>
</mine:agerange>
What about DESCRIPTION tag in RDF?
- - - - - - - - - - - - - - - - - -
In XML-syntax RDF facts are typically given
in DESCRIPTION structure like in the RDF primer example:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<exterms:editor rdf:nodeID="abc"/>
</rdf:Description>
Observe that we could also choose to use the same method to present our literals
in SCL. The last example agerange(John,30,40) would then
simply look like:
<rdf:Description rdf:nodeID="John">
<mine:agerange>
<rdflogic:tuple2>
<rdflogic:object>30</rdflogic:object>
<rdflogic:object>40</rdflogic:object>
</rdflogic:tuple2>
</mine:agerange>
</rdf:Description>
And an example
forall x (man(x) => human(x)) would perhaps look something (but not exactly) like:
<rdflogic:forall variable="x">
<rdflogic:implies>
<rdf:Description rdf:nodeID="x">
<rdf:type rdf:resource="mine:man"/>
</rdf:Description>
<rdf:Description rdf:nodeID="x">
<rdf:type rdf:resource="mine:human"/>
</rdf:Description>
</rdflogic:implies>
</rdflogic:forall>
Alternatively, one could use the Description tag for giving names
to formulas, like this:
http://foo.bar/ourdataitem: agerange(John,30,40)
<rdf:Description rdf:resource="http://foo.bar/ourdataitem">
<mine:agerange>
<rdflogic:object>John</rdflogic:object>
<rdflogic:tuple2>
<rdflogic:object>30</rdflogic:object>
<rdflogic:object>40</rdflogic:object>
</rdflogic:tuple2>
</mine:agerange>
</rdf:Description>
More information about the Scl
mailing list