Re: Modelling "proper names", and other topics

Seth,

I think we're on the same page, or very nearly so, just using different words.

When I prepared my contexts paper (which is still work-in-progress), I 
looked at extending the RDF model as you suggest.  The two options I 
considered were:

    [Ident, Pred, Subj, Obj]

and

    [Context, Pred, Subj, Obj]

the latter being your suggestion, and the former introducing an identifier 
that can be used to reference the statement itself.  In the end I chose the 
former because I see one use of a context being as a composite statement, 
of which a primitive statement might be regarded a degenerate case.  In 
which case, the resulting model is more uniform if the statement itself is 
identified rather than a context.

I feel it is important to allow a statement to belong to an arbitrary 
number of contexts.  (I think this is the only substantive difference 
between our approaches.)  To me, this is part and parcel of the "anyone can 
say anything about anything" philosophy of semantic web developments.

Which one context, then, would we associate with THE statement?  I 
considered that one might introduce a context containing just the one 
statement and use that;  but why bother, why not just label the the 
statement itself?  I think you might, legitimately, view the statement 
identifier as the label of a context containing just that statement.  In my 
view, this is isomorphic with my approach:  one views a context as a 
composite statement, the other views a statement as a primitive 
context.  Take your pick.

Finally, I must note that either of these approaches are not the same as 
RDF as she is defined.  We are working in a field that is attempting to 
create standards for interoperability (someone once said "the nice thing 
about standards is that there are so many to choose from");  but seriously, 
interoperability depends on having common ground.  The common ground that 
we currently have is RDF M&S, so I think it's important to base this work 
in that specification.  The only way I know of to do that is through 
reification, and in my contexts document I show how my model is merely an 
alternative (slightly restricted) "notation" for standard RDF.

John McCarthy, in his paper on contexts, also points out that if one uses 
just FOL then reification is needed to construct the association of 
statements with contexts.

<sidebar>
In a private message, Wolfram Conen has pointed out that this does not 
necessarily have to apply to RDF, and argues that the reason that 
reification is needed with is to overcome a structural deficiency in RDF -- 
namely the lack of recursive nesting of statements in RDF triples, such as:

    [pred, subj, obj]       -- simple statement

    [[pred1,subj1,obj1],
     [pred2,subj2,obj2],
     [pred3,subj3,obj3]]    -- nested statements

I.e. lacking the ability to include a statement as a resource in another 
statement (if I have understood correctly).  In any case, I come from the 
view that RDF per M&S is what we have, and that I'll try to build upon 
that.  I'm happy to create new models if there is a clear mapping back to 
basic RDF.  Any way you slice it, I can't see how to map these ideas to 
standard RDF without invoking reification.
</sidebar>

#g
--



At 07:48 AM 11/7/00 -0800, you wrote:
>Graham Klyne wrote:
>
> > The reason is to distinguish between different _uses_ of a property:
> >    [SomeCity] --properName--> "Boston"
> > and
> >    [me] --properName--> "Graham"
> > are two different instances of "properName".  The only way I know in RDF to
> > distinguish them is through reification.
>
>Well in the case of two different instances of a properName, Im thinking of
>doing it as follows.  Take the example of your calling me "Seth Russell" 
>but my
>11 year old son calls me Popa.  So the RDF triples end up being:
>
>[me] properName "Seth Russell"
>[me] properName "Popa"
>
>The question (i think you raise) is how does one name show up in one context
>and not another.   Well, in my implementation of the RDF graph I add another
>element, turning the triple into a quad as follows:
>
>[C1] [me] properName "Seth Russell"
>[C2] [me] properName "Popa"
>
>Where [Cn] is just a node of type context.   In fact such a node would be no
>different than your "container class" [1] but would be instantuated by the
>extra quad above rather than as objects of the property "--rdfc:quotes-->".
>The context nodes would form a hierarchy over a property (probably the inverse
>of rdfc:member)  very much like a class hierarchy.   There would be 
>another set
>of properties (say rdfc:vocab) hanging off the context nodes  that would point
>to words.   Following the context tree upward for inheritance and downward 
>to a
>set of vocabulary, we could always evaluate any context node to a set of
>words.   That set of words is what would be presented to the user as the
>definition of the context.
>
>The user interface would allow for navigating these word sets.  You can easily
>see how,  as the context nodes are navigated,  different assertions will show
>up.   In the example above,  when I have selected [C2] and am seeing the
>vocabulary set  {Jason, Pokemon, Mom, school, GameBoy } in the context window,
>I would automatically expect [me] to be called "Popa".   Look ma, no
>reification!
>
>Does that make sense?   Can you think of a case where this contrivance would
>not work?
>
>How would you do it?
>
>[1]
>http://public.research.mimesweeper.com/RDF/RDFContexts.html#3.1.3.1Ageneralcontainerforsetsofresources|outline
>
>Seth Russell

------------
Graham Klyne
(GK@ACM.ORG)

Received on Wednesday, 8 November 2000 13:14:22 UTC