W3C home > Mailing lists > Public > semantic-web@w3.org > May 2009

Re: RDF: a suitable NLP KB representation (Was: Owning URIs (Was: Yet Another LOD cloud browser))

From: Dan Brickley <danbri@danbri.org>
Date: Wed, 20 May 2009 10:34:25 +0200
Message-ID: <4A13C091.5070208@danbri.org>
To: David Huynh <dfhuynh@alum.mit.edu>
CC: Sherman Monroe <sdmonroe@gmail.com>, Linked Data community <public-lod@w3.org>, semantic-web@w3.org
On 20/5/09 07:44, David Huynh wrote:
> Sherman Monroe wrote:
 >> That's when I was turned on
>> to Frame Semantics, which I immediately praised, it is by far the most
>> expressive and elegant knowledge representation framework for NL I
>> have come across (although, it's been 3 or 4 years since I really
>> looked). In short, frame semantics sees all sentences as a "scene"
>> (like a movie scene) and the nouns all play "roles" in that scene.
>> E.g. a boy eating is involved in a ConsumeFood scene, and the actors
>> are the boy, the utensil he uses, the food, the chair he sits in. So I
>> choose framesemantics as the KB model for Cypher grammar parser output.
> Thanks, Sherman, for your story. I had a "history" with Semantic Web
> technologies, too, since 2001. Data on the Web is inevitable. I just
> want to figure out ahead of time what it will actually be like.
>
>> This sent off lightbulbs for me, I went back to RDF, and saw that, low
>> and behold, frames can be represented as RDF, the scene types being
>> classes, a scene instance (i.e. the thing representing a complete
>> sentence) being the subject, the property is the role, and the object
>> is the thing playing that role, e.g:
>>
>> EatFrame023 rdf:type mlo:EatFrame
>> EatFrame023 mlo:eater someschema:URIForJohn
>> EatFrame023 utensil someschema:JohnFavoriteSpoon
>> EatFrame023 mlo:seatedAt _:anonChair
>> EatFrame023 foaf:location someschema:JohnsLivingRoom
>> EatFrame023 someschema:time _:01122
>> EatFrame023 truthval "false"^booleanValueType
>>
>> dbpedia:Heroes(Series) rdf:type dbpedia:TVShow
>> dbpedia:Heroes(Series) dbpedia:showtime _:01122
>>
>> _:01122 rdf:type types:TimeSpan
>> _:01122 types:startHour "20"^num:PositiveInteger
>> _:01122 types:startMinutes "00"^num:PositiveInteger
>> _:01122 types:endHour "21"^num:PositiveInteger
>> _:01122 types:endMinutes "00"^num:PositiveInteger
>> _:01122 types:timezone "EST"
>>
>> This says: /No, John didn't eat in a sandwich in a chair in his living
>> room using his favorite spoon, during the TV show Heroes/. Do you
>> still believe RDF is incapable of expressing complex NL statements?
> Yes, I still believe. :)

Skeptical? Me too, here. You have to be pretty careful with negations 
expressed over representations that are shipped around in RDF triples.

 >> EatFrame023 rdf:type mlo:EatFrame
 >> EatFrame023 mlo:eater someschema:URIForJohn
 >> EatFrame023 utensil someschema:JohnFavoriteSpoon
 >> EatFrame023 mlo:seatedAt _:anonChair
 >> EatFrame023 foaf:location someschema:JohnsLivingRoom
 >> EatFrame023 someschema:time _:01122
 >> EatFrame023 truthval "false"^booleanValueType

What happens when you add properties to EatFrame023, or when you remove 
properties from the description? If the above is true, can I take it, 
omit ">> EatFrame023 utensil someschema:JohnFavoriteSpoon" and pass it 
along to some downstream system in a context that suggests it remains a 
true description?

Detail aside: yes, event-centric descriptions are pretty seductive. In a 
world where everything is constantly changing, at least a true 
description of an event seems something that is timelessly true. But 
they can be super-slippery to compute with, especially in a world of 
partial, fragmented descriptions. They're also hard to manage w.r.t. to 
identification: given two descriptions of an event or frame, how do you 
know whether they refer to different ones? etc.

My dabbling with event modelling came through 
http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html 
where we tried to explore the resolution of some tensions between Dublin 
Core and other metadata vocabularies by articulating everything in terms 
of events. It is very appealing, but ultimately I think the problem with 
describing everything in terms of a giant "what happened?" log is that 
it doesn't directly tell you what the state of the world is at any 
point. And that's what many information consumers (human or mechanical) 
more often need.


>> /What
>> happens if all the worlds databases (e.g. Oracle, Mysql, etc databases
>> out there) could be directly connected to one another in a large
>> global network, all sharing one massive, distributed schema, and
>> people were able to send queries to that network using a Esperanto for
>> SQL?/ The ability of RDF to represent (not sentences but) rows and
>> columns of any database schema imaginable means it can deliver this
>> vision, and the value tied to it.

> And look what happened to Esperanto... After one century, 2 million
> speakers, or 0.025% of the world population.
[...]
> Media are notoriously hard to understand, from what I can understand. If
> we were to say that television was radio but "just" with images, then we
> would be missing something huge. Or that printing was writing but "just"
> much faster. Or that writing was speech "just" recorded on paper.

Or that SPARQL is "just" Esperanto for computers? The metaphor is nice 
but ... just that. As you point out, even non-metaphorical conceptual 
shortcuts can mislead us. Sometimes metaphors can inspire us and show a 
glimpse of the bigger picture. But I don't think they so often help us 
predict what'll actually happen.

> Consumer digital cameras are cameras, but just smaller and cheaper and
> faster to develop. Cell phones are phones but just without cords. Etc.
> etc. Is the Data Web the Web just with data? Just for machines? Is the
> difference just that the user can now combine data from several sources?
> How often is that desirable? (Think of your experience today: how often
> would you be willing to pay $1 for RDF from some web page? Daily?
> Weekly? Monthly?) What are the second-order effects?

And money is just written promises :)

cheers,

Dan
Received on Wednesday, 20 May 2009 08:35:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:29 GMT