W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2000

Re: Modelling "proper names", and other topics

From: Seth Russell <seth@robustai.net>
Date: Mon, 06 Nov 2000 11:56:23 -0800
Message-ID: <3A070CE7.801D2744@robustai.net>
To: RDF interest group <www-rdf-interest@w3.org>
Graham Klyne wrote:

> >[BostonMA] --properName--> "Boston"
> >[BostonMA] --rdf:about-->"normative uri of Boston Ma, if known"
> >[BostonMA] --rdf:type-->[city]
> >[BostonMA]--geographicallyContainedIn-->[USstateMA]
> Applying the properties directly to the object doesn't work, I think.

I think it works just fine at the simplest level of description.  When we delve
into the properName we will always be looking for a literal. If we find a complex
maze there that needs further contextual information to interpret, well fine, but
that shouldn't obscure the fact that we are in search of a literal.  I think the SM
should unfold and not require minute detailed descriptions where such are not
currently available.

> Suppose one has a resource standing for an entity with different proper
> names indicating different contexts of usage...
>     [me] --properName--> [ ] --value---> "Graham"
>     [  ]                 [ ] --family--> "Klyne"
>     [  ]
>     [  ] --properName--> [ ] --value-----> "Dad"
>     [  ]                 [ ] --fatherOf--> [...]

I think its simpler for that maze to hang off of only one arc.  In the context of
your daughter we have (me properName "Dad") whereas in the context of this interest
group we have (me properName "Grahm Klyne").  Almost certainly those two contexts
will not be in the same document.  But If both of those contexts end up in the same
ontology - i like:

[myDaughter]  [me] --properName-->"Dad"
[rdf-interest]     [me] --properName-->"Grahm Klyne"

I like (your?) idea of extending the RDF triple to be a quadruple by adding

> That said, I think the other approach (hanging off the propername
> reification) is cleaner.

I see no reason to reify here.

> ... I think it's more a (misplaced) desire to avoid the perceived overhead
> of reification.

I have more troubles with reification than just the overhead.  When to reify and
when not to reify?  Since this will always be open to interpretation, it just
introduces more ways that your expressions will not interoperate with my
expressions. The inference paths for reified statements is not the same as the path
for their non reified cousins.  I would like to reify only when im talking
specifically about a statement and only if the reified statement must be the
subject of my description - see [Oedipus].  But you seem to want to reify for many
other reasons - our stuff is not going to work well together for that reason.  I
would like my inference engine to be able to operate within a given  context - for
example what you believe to be true - since context can bracket what you believe
from what i believe, there is no reason for me to reify either the one or the other
and i can use the same engine for both.  If one is reified and the other is not,
then all the inference paths will be incompatible.  Yuck!

[Oedipus] http://robustai.net/ai/Oedipus.htm

> It's difficult to shake off the feeling that reification is inherently
> clumsy and inefficient, hence tend to try and avoid it.

I think everything that can be done with reification would be better done with

> (One needs to be
> clear that the abstract model is not an implementation blueprint.)

I take the abstract model to be just labeled directed graphs.  All implementations
should tend towards the same graph - otherwise what are we doing here?

> What's this "mime/topic" thing?

I guess its a simpler serialization of labeled directed graphs.

> Which bit is hung off a property node?

The node with the "topic: needsHelpWith" has the description: "<topic> knows how to
make <object> work, but doesn't program fast  enough to make <object> work" hanging
off of it.  It defines what the statement "needsHelpWith: MyMemory" means.

> It occurs to me that the Conceptual Graph (CG) graphical form may be more
> appropriate for the kind of approach we discuss above than the normal RDF
> graphical presentation.
> CG uses nodes for subject, object and property.
>    [Subject] --property--> [Object]
> becomes
>    [Subject] --> (property) --> [Object]
> Now property is a node rather than a line, it might be used as the source
> or destination for some other property.  Effectively, it could be seen as
> standing for the reification for a statement.

In RDF the property is also a pointer to a resource.  Therefore that resource is
available to "hang" other properties off of.  Why isn't CGs just an alternate
mentography for the RDF model?  When we are operating at the level of the model
(labeled directed graphs) what difference does your distinction provide?

<signature format='mime/topic'>
topic: Seth Russell
email: seth@robustai.net
properFirstName: Seth
properLastName: Russell
properMiddleName: <none>
instanceOf: person
authorOf: http://robustai.net/ai/symknow.htm
needsHelpWith: MyMemory

topic: needsHelpWith
description: <topic> knows how to make <object> work, but doesn't program fast
enough to make <object>

topic: mime/topic
isA: language syntax
description: Designed to be easily readable by humans and easily translatable to
RDF for machines.
Received on Monday, 6 November 2000 14:55:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:46 GMT