W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2001

Reified Statements Using Restrictions

From: Sean B. Palmer <sean@mysterylights.com>
Date: Mon, 14 May 2001 17:09:03 +0100
Message-ID: <040a01c0dc92$f477c600$58d893c3@z5n9x1>
To: <www-rdf-logic@w3.org>
Cc: <www-rdf-interest@w3.org>, <w3c-wai-er-ig@w3.org>
For EARL [1], we are looking to build a model utilising two types of
higher-order statements. However, RDF does not currently provide a
mechanism for doing so. My question is: are there any complications
that I haven't seen yet with using DAML restrictions on the
reification properties (rdf:subject, rdf:predicate, rdf:object) and
then declaring something as being a sub class of the intersection of
those restrictions? In other words...

   :MyStatement daml:intersectionOf
       ([ daml:onProperty rdf:subject;
          daml:toClass :MySubjClass ]
        [ daml:onProperty rdf:predicate;
          daml:hasValue :myProp ]
        [ daml:onProperty rdf:object;
          daml:toClass :MyObjClass ]) .

And hence by implication:-

   :MyStatement rdfs:subClassOf rdf:Statement .

This is the only method for constraint that I can work out for when
you're building models that often take on reified statements as their
subjects/objects, and you want to constrain those somehow. For
example, ":MyObjClass" could be a sub class of rdf:Statmeent itself,
and hence you can build up complex data models very quickly using
this. If anyone could provide further assistance or comment, I would
be grateful.

I realise that reification is a tricky subject, but it must be
accepted that higher-order statements are not only useful, but
required in some data models. It must also be accepted that people are
wanting to build stable models utilising higher-order statements right
now... the sooner this is sorted out, the better.

[1] http://www.w3.org/2001/03/earl/

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Monday, 14 May 2001 12:27:43 UTC

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