RE: anonymous nodes

> Well certainly where the community can adopt effective naming 
> conventions,
> we should use those in preference to descriptions.  Yet there 
> are limits to
> effective naming.  For example, there are billions of people 
> .... i see no
> *politically* feasible method of agreeing on a global URI 
> structure to name
> them all ... do you?  Each of those billions of people have 
> billions of
> ideas .. any one of which we might want to talk about in RDF 
> ... some of
> those ideas are the same and we would want them to have the 
> same URI  ....
> alas it's impossible.   In fact as we stand here today I 
> don't even know a
> way that I can give myself a URI that will stick and be used by other
> people, do you?

But that's not the same thing as not requiring that *whatever* URI is
used to identify a person, *some* URI is used -- rather than some
template of properties that get's hung off an anonymous node and
which potentially can ambiguously match resources not equivalent
to that intended.

> > While I certainly subscribe to the need to be able to define
> > axioms based on queries, and that such queries may not care what
> > the actual identity of the resources are, operating only on
> > the basis of their properties -- eventually, if either the
> > explicit or inferred knowledge is to be useful outside the
> > scope of a given system (such as to e.g. some other agent
> > or a human needing information) then those resources will
> > ultimately have to have some recognizable and globally
> > unique identity, no?
> 
> No.  But yes, we do need our communications grounded in terms 
> that we agree
> upon .. and, yes, to the extent that we cannot agree to use 
> common terms, we
> have no communication.   Interestingly enough the verbs (RDF 
> property names)
> are more important than the nouns.  That's why we started SWAG
> 
> http://purl.org/swag/
> 
> Note that this name works because there is a method to 
> dereference it !

Uhhhh...  let's not get started on that old name versus location
flamefest again...  The above URL is a location, not a name (or
at best, it's the name of a location ;-)

> > How does it help if, after your above axiom is applied, I
> > do a query such as 'get me all resources X where [X gar poop]
> > and I get back X = [] or X = G28998_2898193282.28281. Not
> > particularly informative, eh?
> 
> No but that's not the way the example would work ... in fact 
> it would look
> more like that were we to try to use only URI.   You query 
> should return
> [foo bloop; bar goop].

Should? Who says so? What paragraphs of the RDF or RDF Schema specs
say so? How can I trust that all systems based on the RDF or SW
standards in general will do so? Just because that's what *should*
happen does not mean that is what *must* happen according to the
standards or what *does* happen in a given system.

The SW will only be as good as the standards that define it.

> > It is true that we will never escape implicit knowledge or the need
> > to make statements about things where we do not know their precise
> > identity, but those should be the exceptions to the rule, and the
> > general machinery of RDF should discourage (or at least not 
> encourage)
> > the definition of inexplicit knowledge.
> 
> Ok, I agree that RDF should encourage the use of URI .. which 
> it certainly
> already does.  I'd even want the W3C to provide some more 
> practical guidance
> in the process of assigning URI to things other than internet 
> retrievable
> documents .... otherwise there is no reason to expect 
> anything but chaos,
> in which case the URI become useless.  But at the same time 
> we should know
> that the Tower of Babel is a reality, and not try to wish it away.
> Building a global system that assumes that every thing will 
> have an explicit
> name which every body uses to identify it,  is just nonsense. 
>  Rather, I
> think,  we should build mechanisms into our semantic web systems that
> attempt to do fuzzy matches on properties to identify entities.

Well, I think the solution has to be a balance of both, not just
either or. Yes, we need to be able to do fuzzy matches and deal with
ambiguous and/or conflicting knowledge, but also we must ensure that
the foundation (the core data models and manditory functionality) is
explicitly defined, maximally constrained, and maximally efficient.
Because the former is exponentially complex, the more explicit, simple,
and regular the latter is, the better off we'll all be.

Eh?

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Thursday, 16 August 2001 05:41:13 UTC