W3C home > Mailing lists > Public > www-rdf-logic@w3.org > December 2000

Re: A modest proposal for reforming RDF

From: Dan Connolly <connolly@w3.org>
Date: Wed, 20 Dec 2000 11:07:30 -0600
To: Drew McDermott <drew.mcdermott@yale.edu>
Cc: www-rdf-logic@w3.org
Message-id: <3A40E752.8C96C57@w3.org>
Drew McDermott wrote:
> 
>    From: Dan Connolly <connolly@w3.org>
> 
>    I don't really see what your language has to do with RDF, if you're
>    not serializing a graph.
> 
>    Serializing a graph is what RDF is all about; semistructured data,
>    graph merging, all that.
> 
>    It's reasonable to conclude, after the sort of investigation that
>    we've been doing, that trying to shoehorn logical formulas
>    into RDF is a losing game, and take some different approach
>    such as yours. But I wouldn't call that "reforming RDF";
>    I'd just call it a new language.
> 
> I guess I've been misled by this paragraph in the RDF document:
> 
>   The broad goal of RDF is to define a mechanism for describing
>   resources that makes no assumptions about a particular application
>   domain, nor defines (a priori) the semantics of any application
>   domain. The definition of the mechanism should be domain neutral, yet
>   the mechanism should be suitable for describing information about any
>   domain.
> 
> It's not obvious that serializing graphs is a key goal.

OK... I guess my argument is reduced to: your proposal doesn't
layer neatly on a bunch of RDF software in development that
is all based on graphs/triples.

But all that software doesn't grok functional terms, negation,
nor universal quantification, which are things I want,
and after looking at your proposal again, it seems more
feasible to write the sort of software I'm interested
in (proof checkers) to support this syntax than to
support a strictly triple-based approach.


> Howeve, you're right that it's reasonable to have a way of serializing
> graphs in XML.  I would expect such a serialization technique to
> address issues such as distinguishing between directed and
> undirected graphs, making it clear when more than one edge is allowed
> between two nodes, keeping track of cycles or declaring their absence,
> etc.  I wouldn't expect it to have something like rdf:Alt, whose
> meaning depends on interpreting subgraphs as having truth values.  But
> perhaps RDF will evolve toward a true graph-serialization language.
> (An interesting goal might be to express an arbitrary Java object in
> RDF.  That would seem like a good candidate for a graph for which the
> issue of the truth value of subgraphs doesn't come up.)

Yeah... we have a working group doing that; the name is perhaps
misleading:

	XML Protocol
	http://www.w3.org/2000/xp/

but the charter is more clear:

[[[
A mechanism for serializing data representing non-syntactic data models
such as object
     graphs and directed labeled graphs, based on the datatypes of XML
Schema. 
]]]

--         XML Protocol WG Charter
http://www.w3.org/2000/09/XML-Protocol-Charter#scope
Tue, 24 Oct 2000 09:01:32 GMT


The question of how much technology RDF and XP should share
is an interesting one...

> In the meantime, it seems to me there is a need for an XML-based
> notation for logical statements.  I don't think it needs to look
> radically different from RDF, but it does need to give up the graph
> model.

OK... here are my comments on your proposal, as I read it.
I think the main thing I don't understand is how MP/MT bottom out; i.e.
how lookup(c, propName) and denotation(URI) work.
I'd like to see a worked-out example of how MP and MT work;
i.e. start with a fairly complex formula and show the results
of evaluating MP on it.





Reforming RDF
http://www.cs.yale.edu/homes/dvm/daml/proposal.html
Wed, 13 Dec 2000 23:40:15 GMT

| The disadvantage is that we can't assert a complex
| expression without asserting its parts. 

That's true enough; there's no syntactic sugar for quoting, but...

| I have an alternative proposal, which does little violence to most
| uses of RDF, but does away with the ability to assert an arbitrary
| piece of an expression just by referring to it. 

Which ability is that? Just referring to the parts of a statement
doesn't assert it.



| Within the scope of a variable binder such as Forall, ref="name"
| is like resource="#name", except that the link "#name" and the
| resource pointer are global, whereas var and ref set up a purely
| local link. (So we can reuse them without fear of ambiguity.) Example: 

I don't see this. The string "xyz" is 'global' in the sense
that it's the same string everywhere in the world. A use
of a symbol as a variable can be scoped regardless of the
spelling of the symbol name; I see no reason not to use
"#name", an abbrevaiation for http://...address-of-this-document#name,
as a variable symbol name. But... hmm... there's not
much reason *to* use #name either. It doesn't matter.


|       <rdf:Type resource="http://social.org/categ-ns#Vote">

"type" is spelled with a lowercase "t" in RDF-of-Jan'99. I assume
you don't mean anything by the capitalization.


| With no explicit ID, var, or about, the description behaves like #1,
| but there's no constant to refer to. 

Perhaps it's more straightforward to say that with no explicit ID,
it's short for a <rdf:Exists> construct?


| We interpret a Description/ID at the top level as declaring that an
entity exists.

I don't know what an "entity" is. If that's a term you're introducing
in this document, that's very well, but if it refers to something in
"traditional logic-based tools", please explain.

| The expression const="ont:action" uses a new notational idea, that of
a constant.
| This is simply a name (in the namespace sense) used to refer to
something. 
| Perhaps RDF already allows this, but if so it isn't obvious.

No, the RDF syntax doesn't have a way of using qnames (prefix:localname)
as the objects of statements. The reason why not is historical and
has gone away, though, I think.


This is very interesting...


| There may be a need for pointers to pieces of RDF considered as data
objects,
| or considered as places in cyberspace. We should introduce an
alternative
| field, perhaps 'expID,' for this purpose.

TimBL has tried to convince me that there's
some fundamental confusion around whether ID="foo" can be used
for both "this piece of RDF/XML syntax, in case you are, for example,
styling it for display" and "the subject of this bunch of assertions."
He hasn't managed to convince me, but I expect he would be happy with
expID, as it seems to address his concern.

Unfortunately, it turns out to be a tease:

| I will ignore
| expID's in the rest of this proposal. 

Oh well... I'll try to find a use case/test case where
it matters...


| propertyElt  ::= '<' propName refAttr '/>'
|                 | '<' propName  '>' term '</' propName '>'
|                 | '<' propName  '>' string '</' propName '>'

RDF has this parseType="literal" mechanism for using
arbitrary XML content, rather than just a string, as the
value of a property. You don't seem to have captured
that (though it looks easy to add).


| MP is defined by the following equations: 

Hmm... this reminds me of the XSLT-based RDF parser I hacked
up... I wonder if I could hack up MP in XSLT...


| where g is a new symbol. 

Huh? I don't see any g.

|  MP(c + [* = v]

What's this [* = v] notation? Is * just a regular variable name?
I assume so...

| If the typeSpec is missing, it defaults to <rdf:Type
const="Something">.

Hmm... the syntax allows just one type... types seem to be
integrated into the syntax, rather than just being regular
assertions about things. I'm not sure I understand...

Anyway... Something should be grounded globally, no? i.e.
rdf:Something?



Er... the definitions seem to bottom out at:

| MP(c, '<' propName refAttr '/>')
|
|    = lookup(c, propName)(lookup(c, *),
|                          MT(c, refAttr))

I don't have a good feel for what lookup(c, propName)
means. I don't see how c could contain a binding for propName...
unless the algorithm is sort of itialized with c containing
the mapping from all URIs in the world (or at least: some
relevant set of the URIs in the world) to what they mean.
Hmm... I guess I could get my head around that; is that
what you meant?


| MT(c, a) = MP(c, a) if a is an Assertion or Description

Er... is that going to end up with the meaning of
such a term being 'true' or 'false', or with the
meaning of such a term being a forumula?


| Note that the op applies to the inside of the lambda expression
| in this case, as opposed to the outside for the similar
| Description. If this is too inconsistent, we could change it. 

I'm confused about terms with variables... what are
they for? was there an example?


| MT(c, 'resource=' URI) = denotation(URI)

Er... what does denotation(URI) mean? Why
didn't you use lookup(c, URI) as before,
in the propName case?


| MT(c, 'const=' s) = lookup(c, s) [which searches the appropriate
namespace]

I'm confused... I assumed you were just using
qnames as short-hand for URIs, independent
of this lookup() thing; but now it seems
you're using lookup() both for the
c + [var=val] bindings that you introduce
and for the syntactic xmlns= bindings.
???


| 1.If an Assertion uses a standard operator o (rdf:And, rdf:Or, etc.,

What does etc. mean here?


| 4.If all the arguments of a Term have label rdf:Arg,

as opposed to...? Oh! I get it... arguments are labelled,
rather than positional... and labelling them
all rdf:Arg says the order doesn't matter. nifty.




-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 20 December 2000 12:07:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:37 GMT