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

Modelling "proper names", and other topics

From: Graham Klyne <gk-lists@dial.pipex.com>
Date: Sun, 05 Nov 2000 22:56:42 +0000
Message-Id: <>
To: Seth Russell <seth@robustai.net>
Cc: RDF interest group <www-rdf-interest@w3.org>
At 10:26 AM 11/4/00 -0800, Seth Russell wrote:
>Graham Klyne wrote:
> > I felt that it was important that the proper name Boston referring to the
> > east coast US city should be distinguishable from the same proper name
> > referring to a small English town, etc.  I couldn't see how that
> > distinction could be drawn using just literals.
>I don't think the distinction can be drawn just using literals and I don't see
>how the extra node helps draw it either.

I had thought that one could use additional properties to draw the 

>   Let's face it, the proper name
>"Boston" stands in the same relationship to 2 cities.  But how about?
>[BostonMA] --properName--> "Boston"
>[BostonMA] --rdf:about-->"normative uri of Boston Ma, if known"
>[BostonMA] --rdf:type-->[city]

Applying the properties directly to the object doesn't work, I think.

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--> [...]

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

>Another stupid question:  Are we using rdf:type for --instanceOf-->[A 
>class] ??

I am.

> > However, your idea of hanging additional info off the properName property
> > arc (or, strictly, off the reification of the properName statement) is, I
> > think, truer to the concept here.  The proper name string "Boston" is after
> > all just a string.  It's the way it's used (the entities to which it is
> > applied) that distinguish its different uses.
>I think the ability to factor information into the property node is an
>overlooked power of labeled directed graphs (i.e. the RDF model) - see my
>signature for example.

I guess so...

>    This probably comes about because everybody seems to
>want to put information  belonging to the property nodes in separate scheme
>files that are processed differently by the program and basically inaccessable
>to the author.   The solution being, imho, to stop doing that.

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

It's difficult to shake off the feeling that reification is inherently 
clumsy and inefficient, hence tend to try and avoid it.  (One needs to be 
clear that the abstract model is not an implementation blueprint.)

>PS: Should I worry about this cross posting between rdf-interest and 

Hmmm... maybe.  because this is more about expressivity than inference, 
I've restricted my response to -interest.

><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.


What's this "mime/topic" thing?

Which bit is hung off a property node?

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]


   [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.


Graham Klyne                       Content Technologies Ltd.
Strategic Research              <http://www.mimesweeper.com>
Received on Sunday, 5 November 2000 17:09:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:32 UTC