W3C home > Mailing lists > Public > public-swbp-wg@w3.org > June 2005

Re: How to state simple facts in RDF

From: Christopher Welty <welty@us.ibm.com>
Date: Wed, 29 Jun 2005 11:02:09 -0400
To: Lars Marius Garshol <larsga@ontopia.net>
Cc: public-swbp-wg@w3.org
Message-ID: <OFBFBE6038.A1233A15-ON8525702F.004F3666-8525702F.00529A87@us.ibm.com>
I don't know anything about topic maps, but it sounds like from your 
syntactic example:

[a] is-bankrupt(barings-bank : company)

that you have some notion of "strong typing" (aka "sorts" in logic), that 
is, there are unary predicates that are somehow more essential than 
others.  There has been a lot of work on this in the research community, 
and we are trying (through this forum) to educate the SW community about 
it, not surprising that many don't know about it, or even believe it 
doesn't exist.

There are a number of ways to do this.  Here are three:

you can create special relations to differentiate the "essential" from 
"nonessential" associations to classes:

[b] essentialType rdfs:subproperty rdf:type
    nonessentialType rdfs:subproperty rdf:type
    barings-bank essentialType company
    barings-bank nonessentialType bankrupt

or create special classes:

[c] EssentialClass rdf:type rdf:Class
    NonessentialClass rdf:type rdf:Class
    Company rdf:type EssentialClass
    bankrupt rdf:type NonessentialClass
    barings-bank rdf:type company
    barings-bank rdf:type bankrupt

Of course most non-essential classes can just be turned into relations:

[d] barings-bank rdf:type Company
    barings-bank financialStatus bankrupt

These could all also be expressed in OWL, of course, but it would be a 
little different.

Assuming you are interested in automatically translating the syntax of [a] 
into rdf, I think [b] would be easiest to generate automatically from 
syntax, [c] is not much harder (it may require two passes) and  would be 
my preference, as I believe it is closer to what you really mean.  [d] 
would probably be hard to do automatically.

I'm expecting that, in order to do translation between any two languages, 
some special vocabulary will be needed in each to ensure as much of the 
semantics of the "source" language is preserved.  So both [b] and [c] 
would require some special vocabulary to support translation.

-Chris

Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532     USA   
 
Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
Email: welty@watson.ibm.com, Web: 
http://www.research.ibm.com/people/w/welty/



Lars Marius Garshol <larsga@ontopia.net> 
Sent by: public-swbp-wg-request@w3.org
06/29/2005 09:09 AM

To
<public-swbp-wg@w3.org>
cc

Subject
Re: How to state simple facts in RDF








* Michael F. Uschold
|
| Rdf:type is fine for many such examples.

It does seem to work, and work well, in some of the cases, I agree.
 
| However, it is not always such a good idea to create special
| classes/types for every such fact.
| For example: 
|                My car is red.
|                This food tastes good.
| 
| To use rdf:type food these statements requires one to create
| artificial classes/types for such notions as RedThings, or
| GoodTastingThings.
| 
| One can do it, but it is not always what you want.

I agree, and the RDFTM work is one case where this isn't really what
we want, since although it works to turn

  is-bankrupt(barings-bank : company) /* LTM syntax */

into

  (barings-bank, rdf:type, BankruptCompany)

this causes difficulties with roundtripping back to topic maps, since
we can't then easily distinguish between types that are "real types"
and types that really represent "unary associations".

Does anyone know of other good modelling patterns for this in RDF? Or
do we need to create a special
rdftm:ArtificialClassThatIsReallyAUnaryAssociationType class?

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
Received on Wednesday, 29 June 2005 15:02:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:10 UTC