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

Re: Managing Co-reference (Was: A Semantic Elephant?)

From: Peter Ansell <ansell.peter@gmail.com>
Date: Fri, 16 May 2008 11:27:45 +1000
Message-ID: <a1be7e0e0805151827u28d06e75k92cf1bd0d96ffc4a@mail.gmail.com>
To: "Harry Halpin" <hhalpin@ibiblio.org>
Cc: "Semantic Web Interest Group" <semantic-web@w3.org>

2008/5/16 Harry Halpin <hhalpin@ibiblio.org>:
> Peter Ansell wrote:
>> 2008/5/16 Jim Hendler <hendler@cs.rpi.edu>:
>> Fwiw, seems to me what we need is rdfs:sameas - with owl: sameas being a
>> special, more restricted, case - like rdf vs owl class defs
>> I agree. There is a big difference between being able to merge RDF
>> graphs and merge OWL "Things".
> There's a pretty convincing argument that it is likely impossible to get to
> manage co-reference completely down to the level of what Bernard calls the
> "signified" or most people think of "a thing in the real world." For those
> that missed the IRW2006 workshop, called "In Defense of Ambiguity" and its
> finally written down [1],  I'd recommend reading it for those interested in
> the argument that a URI can never really identify one thing, even with
> inverse functional properties :)
> The best we can hope for is descriptions of these things and sharing those.
> This just doesn't apply to informal semantics of "things in the real world"
> but also to the formal semantics of any SemWeb language,  as any
> model-theoretic interpretation has lots of interpretations in a domain which
> will satisfy it, so that the "referent" is never pinned down exactly.

I don't like the idea of forced ambiguity in the same way as the
undecidability of logic systems isn't that attractive (although it is
inevitable). The referrent is pinned down in contextual situations by
its use IMO, despite all efforts of the modeller to say otherwise.
Globally useful Inverse functional properties are a pipe dream IMO,
although in really simple circumstances they seem to be useful, such
as FOAF person and email address, where the latter, if it is a
personal distinct email address, can be utilised to refer to the given
person consistently in a non-URI/RDF context.

>> I use owl:sameAs to do the former when
>> the properties are all going to be relevant to both, but the two URI's
>> still don't necessarily match a given whole-world OWL structure.
> Trying to get to the practical ramifications of the argument, so feel free
> to help me here if I've misinterpreted thigns. I think the real issue here
> is one again, not of resolving co-reference on some sort of "deep" level,
> but that of when to import descriptions, which on the Semantic Web are
> triples. In essence owl:sameAs is rather strong since for URI_1 owl:sameAs
> URI_2, every triple that  applies to URI_1 must also apply to URI_2 and vice
> versa. So, in essence, all these triples must be imported, no?

I am not sure what to make of the "imported" concept, as I don't see
it as a cross-pollination of properties, you are just told that you
can treat the predicate, object tuples, which will always stay on the
other URI, as being relevant still when utilised with this concept. I
don't think that the reasoning process should augment the knowledge
structure, ie, don't actually change the triples by "importing" them,
merely offer them as extras. Of this importing procedure is never ever
going to be useful to a OWL modeller or reasoner, as the model is
dynamic not static, but it could be useful to an RDF reasoner or query
engine, as there is no explicit concept of Classes which must have
properties explicitly added to them before creating instances as
completely valid instances of the Class. In reality I see an
rdfs:sameAs as merely saying two bags of properties can be picked out
of when one is not sure about the subject URI in a query. Ie, from the
Reasoning point of view I would accept the following as a sufficient
WHERE clause (I think)

 ?s <http://myshared.net/reference#property> ?o .
 OPTIONAL(?sOther rdfs:sameAs ?s).

Making assumptions about "?s a yetAnotherowlOntology:SpecificClass"
would in some ways break the assumptions that this makes with
reference to the fact that ?sOther and ?s are interchangeable without
the statement about which class ?s is.

>> rdfs:seeAlso has never been a big attraction to me due to its lack of
>> actually saying anything about what you are going to get, possibly due
>> to its colloquial use with FOAF and sending you off to a random foaf
>> file for more information about an, as yet unnamed, entity.
> While rdfs:seeAlso does not have this constraint, i.e. it is just another
> predicate, so it doesn't really state anything. Should it followed? Should
> all triples in seeAlso be added to the graph of an agent encountering
> rdfs:seeAlso? Who knows? It seems "no."

Constraints are derived in part from usage, and a common vocabulary
develops these uses as a result of its shared distribution and usage
assumptions. rdfs:seeAlso is most certainly not "just another
predicate" in this way. I wouldn't assume anything at a graph level
about adding, as I said above about avoiding augmenting the data based
on ones assumptions. If a Graph is going to be used by OWL as
definitive it could easily break any complex restrictions that were
placed on the original usage which without augmentation would still be

> What we seem to want is something like rdfs:seeAlso that forces one to
> import some statements, but not necessarily everything (ala owl:sameAs).
>  Perhaps the real issue is that people want some sort of "partial" importing
> of triples, i.e. a semantics for owl:imports (or something similar,). That
> one can say for URI_1 owl:kindaSameAs URI_2, where that means concretely
> some finite triples that apply to URI_1 also apply to URI_2, but not
> necessarily all . That's usually how humans communicate, by sharing "just
> enough descriptions" to get the job done, not necessarily buying everything.
>  But what would that mean implementation-wise? How can one avoid just having
> to "list" these triples and put them in via an owl:imports, but maybe bundle
> them up in some nicer manner?

owl:imports is explicitly at the Graph (really owl instances) level of
course, which is where seeAlso may actually be intended to be, but it
does not bring that across very well. I see it to have the same
semantics that an "other interesting links" section has on a web page,
indicating that the author thought they were interesting but that
shouldn't hamper your usage of this page depending on whether you
accidentally followed the link for curiosity purposes or not. It is
not a useful solution to make people cherry pick properties to augment
their own graphs. Other than the fact that triples don't generally
have identifiers which would be required for this purpose, it would be
easier to just restate the small set of agreed properties within the
current Graph and its Subject URI.

Some people have brought up the idea of skos:related for this, but it
has its forced dependency on skos:Concept and the things that you have
to accept in that area instead of being a generic statement, and hence
is unusable for a general solution.

> Peter Patel-Schneider and Bijan Parsia had a nice paper on owl:imports this
> at IRW2006[2].

I don't agree with their assumption that the Semantic Web is "just" an
extension of the WWW. I don't think idea of "defining statements" is
useful either. Definitions are at best suggestions in linguistic
terms, and that is all most people see Ontologies to be. If someone is
misusing a term, in your opinion, you can ignore them but it isn't
likely to gain you as much as attempting to understand how they are
using the term and working with them. Whether they accept your
suggestions is another thing though as the idea that you are more
knowledgeable then they are could easily be misplaced as bigotry.

Seeing owl:imports is used at the graph level, which is effectively at
the level of RDF Literal which happens to have a URI representation,
if you import an HTTP document you can hardly say you are importing an
RDF Resource, you are really just misusing the Resource definition to
double as a HTTP fetch instruction which has RDF information which may
or may not be relevant, but which can be utilised explicitly by
someone looking at your document if you don't have resolvable HTTP
identifiers or you are not using HTTP and you happen not to have
previously found the ontology on the internet. In some ways I think
resolvable namespace identifiers have made owl:imports more useful for
explicit imports, but as noone needs to use them anymore for the
majority of well defined namespaces, why would they as usage defines
that people can utilise the ontology as part of the identifier, *if*
they desire. If you do desire, as people here want to with their
desire to have a consistent co-reference system, then IMO you are
stepping over the cliff into the big bad inconsistent universe of
ontologies defined and controlled by others.

In some ways the semi-democratic Wikipedia is leading the way in this
meaning universe with its "wikilink" which I see as a specific meaning
predicate between linguistic terms, that is not controlled by an
organisation who every now and again publishes a new version in the
classical knowledge publication scenario. Wikipedia is in the unique
position that if you don't like a definition *you* can actively change
*it*, although you may have to argue and provide evidence for your
point, unlike authority based ontologies (such as skos) where you have
to accept others usages in whole with no effective recourse other than
all or nothing. Disjointed outside published upper ontologies are a
big reason why academic colleagues mock the entire goal of the
Semantic Web and part of why they are all going for collaborative
wiki's to define their shared meanings. If you do use shared possibly
unstable meanings, where you can't assure users that you are always
going to be using the term properly, you can't be held accountable
IMO, although that isn't a legal statement or anything, just applying
the anti-retroactive principle to the Web. It would be nice to be able
to freeze the web at a certain point in time so researchers could do
all sorts of interesting things with it, but unfortunately the real
world impinges on idealism here. Even attempting to make large caches
and offer query mechanisms based on that will fail to offer users what
they want once their leave your walled garden.

I think that outside of that discussion, a big rethink of what
"meaning" means (academic pun intended) is needed on top of what they
imply. Everyone talks about meaning without saying what it is they are
trying to achieve by agreeing on a formal meaning. Meaning is like
wisdom, hard to find, but noticeable when *you* get to it.
(apparently.... not that I would know what wisdom is!)

Received on Friday, 16 May 2008 01:28:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:04 UTC