W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

relating S-A and S-B [was: TDL conflicts with the "duh!" requirement]

From: Dan Connolly <connolly@w3.org>
Date: 28 Jan 2002 09:17:21 -0600
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: RDF core WG <w3c-rdfcore-wg@w3.org>
Message-Id: <1012231042.4873.186.camel@dirk>
On Mon, 2002-01-28 at 08:33, Patrick Stickler wrote:
> On 2002-01-28 15:29, "ext Dan Connolly" <connolly@w3.org> wrote:
> > It's true that S-A works better locally, and S-B works
> > better globally, and you have to choose one or support
> > both or whatever. This is an issue with S. But I find
> > it acceptable.
> Nope. Sorry. You can't use both. They are not compatible
> in the same knowledge base.

I'm not sure what you mean by "not compatible".
It's a bit awkward if one party expects S-A and
another party provides S-B, just like if one
party expects English and the other provides
Spanish. but there's no
problem using both in the same file:

	<rdf:Description rdf:about="#Dan">
	  <ex:shoeSizeA s-a:decimal="10"/>

I just told you the same thing two different ways.
I didn't have to contradict myself or anything
in the process.

> What happens when you choose to use S-B and I choose to
> use S-A and then we want to syndicate our knowledge
> but can't because our idioms are not compatible?

Receivers who only understand/expect S-B will miss some
stuff and receivers who only understand/expect S-A
will miss some information. But there won't be
any unsound inferences, contradictions, etc.

Anybody with rules capability can, for example, write
a rule to understand S-A in terms of S-B, or to take
a bunch of knowledge encoded in S-A and automatically
suppliment it with S-B or whatever.

this log:forAll :s, :p, :o, :ip, :olit, :lp.

{ :s :p :o.
  :o :ip :olit.
  :ip a :InterpretationProperty .
  :p :lexicalForm :lp.
  { :s :lp :olit }.

for full details, see


which has rules to turn

I haven't written rules to go the other way, but I don't
see any obstacles to doing so.

But like Jeremy (28 Jan 2002 13:44:38 +0000),
I consider S-B to be the preferred idiom.

> I consider this to be a major show stopper for S.

I can see why it bothers you, but
I think all the alternatives are much worse.

> >> It is no different than
> >> 
> >>  :Bilbo :age "111".
> >>  
> >>  { ?x :age "111" }
> >>  log:implies { ?x a :EleventyOner }.
> >> 
> >> Yet, your implication is based on the implicit
> >> presumption that values are in decimal notation.
> > 
> > No, it's based on a design choice that whatever "111"
> > denotes, it denotes that same thing in all interpretations.
> Hmmm.... Is this an application design choice?

No; it's a design choice for RDF 1.0...
one that I think is already made, in the
deployed applications, by the way.

> How will my application know about your application's
> typing expectations when I get your data?

I think that anything that claims to know RDF
should know that "111" denotes the same thing

> >> If you really want to capture the implication,
> >> you must also specify the datatype which ensures
> >> the expected interpretation of the lexical form.
> > 
> > Nope. All I need to say is that "111" denotes
> > the same thing in all interpretation and
> > the inference follows.
> Well, you're going to have a very tough
> time freely exchanging knowledge with others
> when your expectations about what
> are (to RDF) local names are not shared
> globally by others.

Yes; that's why this must go in the RDF 1.0 spec.

> > Yes, the scalar datatype.
> So RDF datatypes can only be integers or strings?

RDF datatypes can span the range of human expression,
more or less. RDF literals better denote just
one thing each, though. Call it a string if you like,
or a scalar, or whatever.

> >> Merging of literal labeled nodes in S does not assert the
> >> same resource equality as merging of URI labeled nodes,
> > 
> > yes, it does.
> Sergey? Can you confirm that?
> Patrick

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 28 January 2002 10:17:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:08 UTC