- From: Jim Hendler <jhendler@darpa.mil>
- Date: Thu, 17 May 2001 04:04:57 -0400
- To: David Allsopp <dallsopp@signal.dera.gov.uk>
- Cc: www-rdf-logic@w3.org
>Jim Hendler wrote: > > >If so, how are these statements (the actual message content) 'contained' >by the message object, since it can't point at them without reification? > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >For example, we have the triples > >message_01 --rdf:type--> agent:Message >message_01 --agent:timeStamp--> "4:00PM Tuesday" > >and the content of the message, such as: > >Airport_01 --status--> Operational > >How do we assemble these such that we know that the timestamp >appies to the content? Or do we associate the two by convention? >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >(One could nest a serialized RDF/DAML document within the message object >(i.e have a 'content' property that points to a rather long string >literal) but that doesn't seem to be what you're suggesting). > >Alternatively, the description of the Message object merely accompanies >other statements in a document, and it is up to the recipient to notice >it and take appropriate implementation-dependent action. > >Or perhaps I have misunderstood the intended usage; I want to be able, >in principle, to determine the timestamp, origin etc of any individual >statement about any resource in my database/RDF Model. I am unclear how >or if putting a timestamp on a message object would translate to a >timestamps on its constituent statements (which are gathered together >along with those from many other messages in some form of database). > >Regards, > >David Allsopp >DERA Malvern OK - several possibilities - the one I'd suggest is to create a content property, but not fill it with a string, fill it with an anonymous node which itself is the appropriate RDF for the content: message01 :a Agent:AgentMessage ; Agent:timeStamp "4:00 Tues" ; Agent:MsgContent [ Airport:AirportName AirportList:Airport_01; Airport:AirportStatus "operational"] . Now, before people yell too much (and with apologies to Pat, I'm going to ignore some deeper issues and be a real "scruffy") - there is a formal semantics as to what this means with respect to DAML+OIL (remember, we defined the AgentMessage class and its properties in DAML+OIL in an earlier message) -- but the important thing here is the operational semantics we give it -- in other words, if I define the ontology with these sorts of properties, there are some in the RDF community who might claim that I asserted that the Airport actually is operational. But I would argue that I have not done so -- you cannot find this message in any useful way outside of the MsgContent it appears in, and I would make sure my applications knew not to make that inference. There is the issue of whether other applications would know not to make that inference upon reading my RDF/DAML, but again, notice that the anonymous node really isn't the same as making the assertion since that graph never really "appears by itself" -- not something easily formalized without a lot of work (and that is what the whole reification debate really seems to turn on), but in practice it doesn't seem to me to be a tough issue -- I find it hard to believe someone would develop an application that would assume I had asserted this anonymous class to explicitely be true (see Pat's messages), and if they haven't, then all they can really assert is that some particular document (the one this appeared on) seemed to imply that the Airport was operational - again, this could cause problems, but I don't see that there are any show stoppers to fielding things with this syntactic sort of approach (or at least any that aren't almost as bad using reification). What I've done is basically to mimic what the reification is supposed to do -- break my quoted message into a set of arcs/links that have appropriate content - but I've named the links myself, and used the operational semantics to make sure appropriate things happen - not elegant, but very powerful. There's a lot of other issues in the use of this stuff - but for all practical purposes a lot of us have been using techniques like this for a long time, and they work just fine. That said, let me again restate that I do NOT offer this as a great mechanism that solves all problems -- rather, I was trying to show that for practical purposes one can do a lot of tagging and assertions about assertions by careful use of ontologies coupled with reasonable operational semantics. The eventual semantic web may want better, but for those of us who want to start building now, mechanisms like this one should work just fine for a while -Jim H. p.s. For some random mutterings on tags see : http://www.cs.umd.edu/users/hendler/Tags.html For some pointers to stuff about agents, ontologies, and the Sem Web see http://www.cs.umd.edu/users/hendler/ontologies.html -- Prof. James Hendler Program Manager DARPA/ISO 703-696-2238 (phone) 3701 N. Fairfax Dr. 703-696-2201 (Fax) Arlington, VA 22203 jhendler@darpa.mil
Received on Thursday, 17 May 2001 04:03:45 UTC