W3C home > Mailing lists > Public > www-rdf-rules@w3.org > January 2004

Re: DRS guide

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Thu, 15 Jan 2004 12:26:00 -0500
Message-Id: <E36FC161-477F-11D8-927E-0003939E0B44@isr.umd.edu>
Cc: www-rdf-rules@w3.org
To: Drew McDermott <drew.mcdermott@yale.edu>

On Jan 15, 2004, at 11:58 AM, Drew McDermott wrote:

> One can construe "reification" broadly or narrowly.  Broadly, it just
> any means of encoding a triple so RDF won't recognize it as that
> triple.  In this sense both SWRL and DRS use reification.


> The narrow construal (or "construction," if you're a purist), is to
> use the rdf:subject, rdf:predicate, rdf:object vocabulary.

That's the one I'm quibbling with.

>   The only
> reason we use them in DRS is in an attempt to be consistent with
> existing formalisms.  (To be "layered," if you will.)  Or perhaps I
> should say, to avoid appearing to break new ground by use of
> notational variants.

But you do so anyway by encoding argument lists as the value of the 
rdf:object property. I guess I mean if you are going to layer on SWRL, 
SWRL uses a homegrown reification vocabulary. RDF's reification has a 
lot of baggage, IMHO, and thus should be avoided for this sort of 

> This philosophy is why SWRL atoms are now included as DRS atomic
> formulas:
> <Class rdf:ID="Atomic_formula">
>    <unionOf rdf:parseType="Collection">
>       <Class>
> 	 <intersectionOf rdf:parseType="Collection">
> 	    <Class rdf:about="#Formula"/>
> 	    <Class rdf:about="#Functional_term"/>
> 	    <Restriction>
> 	       <onProperty rdf:resource="#term_function"/>
> 	       <allValuesFrom rdf:resource="#Predicate"/>
> 	    </Restriction>
> 	 </intersectionOf>
>       </Class>	
>       <Class rdf:about="&swrl;Atom"/>
>    </unionOf>
> </Class>
> This means that the encodings you used in your examples are two
> different ways to express exactly the same atomic formula: (rdf:type x
> Artist).

Yep. I was just suggesting that there are reasons to avoid the RDF 
vocabulary,  or to extend it in a different way.

> (Neither one represents the variable 'x' correctly, but
> that's an orthogonal issue.)


Bijan Parsia.
Received on Thursday, 15 January 2004 12:26:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:17 UTC