Re: Could owl:sameAs reference non-OWL resources?

From: "Bernard Vatant" <bernard.vatant@mondeca.com>
Subject: RE: Could owl:sameAs reference non-OWL resources?
Date: Tue, 29 Apr 2003 10:51:21 +0200

> Peter
> 
> Thanks for your answer. Some precisions below, and further question at the
> end about owl:sameAs
> 
> > I'm not sure what you are trying to get at with the phrase "OWL
> resource''.
> 
> I guess I mean here an XML element in an OWL document, not the (abstract)
> thing represented by it (also called a resource in RDF land, right). Note
> that I'm certainly biased here by the distinction made in XTM between the
> following.
> 
> <resourceRef xlink:href = "foo">
> used to identify the subject as *being* the information resource found at
> "foo"

i.e., a document or other web-accessible item;

> <subjectIndicatorRef xlink:href = "foo">
> used to identify a subject *somehow defined* by the information resource
> found at "foo"

i.e., something named in a document

> I'm not sure which one of the above is the closest to owl:sameAs, if I want
> to express the topic map concepts in OWL (that's what I am trying to do,
> remember). 

Well, owl:sameAs makes two names refer to the same thing, so it is agnostic
about what is actually identified.  Of course, stating that a web page
and a car are the same thing is probably not a great idea.

> In fact what I would do after your answer and a night over it,
> would be to use in a Topic Map ontology a specific Datatype Property like:
> 
>       <owl:DatatypeProperty ID="subjectIndicatorRef">
>             <rdfs:label>Subject Indicator</rdfs:label>
>             <rdfs:domain rdf:resource="#Topic"/>
>             <rdfs:range
> rdf:resource="http://www.w3.org/2000/10/XMLSchema#anyURI"/>
>       </owl:DatatypeProperty>

Well this is really an issue with how to make sense of
``subjectIndicatorRef'', which is part of the denotation theory of RDF.

> >> What about DAML legacy for instance?
> 
> > No problem, except, of course, that what you probably want is to include
> > the DAML+OIL meaning for any DAML+OIL ontologies that concern this
> entity,
> > which you are not going to get.
> 
> I'm not sure I catch you here. Could you give an exemple?

If you say

	<ex:Person rdf:about="#john">
	</ex:Person>

	<daml:Class rdf:about="ex:Person">
             .....
	</daml:Class>

an OWL system isn't going to understand the daml:... stuff.

> >> Will owl:sameAs ensure backward compatibility with DAML+OIL
> >> libraries? Or support XTM subject indicators? Or UDDI, XRI ... whatever.
> 
> > No.  At least not unless someone builds a system that can handle both OWL
> > and DAML+OIL or XTM or UDDI, or whatever.
> 
> Well, this is indeed the kind of stuff we are up to in Mondeca. Very
> arrogant indeed :))
> 
> If you have a system where the internal representation is not bound to a
> specific markup, you want to be as "syntax-omnivorous" as possible and be
> able to exchange files in various formats. That's why we want to be able to
> swallow both XTM and OWL, and make sense of both internally if possible.
> For example importing an XTM file using OWL elements as subject indicators,
> we want to be able to import the properties asserted in the OWL document
> about those classes. This is not completely obvious, but that's what we are
> working out right now.

Well, sure, you can be as syntax-omnivorous as possible, but you aren't
going to get very far unless you also can abide by the meaning of that
syntax.  For example, a compiler that could read both C and SML/NJ but
didn't have a garbage collector wouldn't be able to do the right thing with
the SML/NJ stuff.

> The round trip I was about is, if a OWL ontology can reference an XTM
> subject indicator, then a system knowing how to parse both XTM and OWL
> would be able to make sense of such references.

Parsing isn't the problem; meaning is.

> > You appear to be asking for a system that can handle
> multiple formalisms.  This is not a trivial thing, and can often be very
> problematic, or even impossible.
> 
> Our semantic ambition has no limits :))

Go ahead, but please don't say that you actually do stuff with OWL unless
you actually do what is needed by the semantic theory underlying OWL.

> Further question, BTW, this time internal to OWL universe.
> How is an OWL parser supposed to deal with owl:sameAs referencing an
> external OWL file? Is it supposed to parse also the referenced file? 

If you mean a URI reference that, if you picked it apart, looks like a
fragment identifier in a different document, then there is no special
meaning.  OWL, like RDF, treats URI references as black boxes.

> Has it
> to check for consistency of properties asserted in the referenced file with
> the ones asserted in the source file about the "same" individual? Has it to
> import those properties, and the objects referenced by those properties,
> and so on ... 

No.  owl:imports is used to do this.

This is a feature of OWL that allows the use of a particular URI reference
without committing to the information contained in any particular document.

> What happens if inconsistencies are found?

Well, if an imported document is inconsistent with the information in the
importing document you have an inconsistency.  This is by design - OWL has
no notion of provenance or precedence.  Adding such notions would result in
a *much* more complex logic.

> IOW, widespread use of sameAs could lead the parsing of a single file to
> trigger the parsing of thousands of ontologies, if not of whole continents
> of the Semantic Web... which is quite frightening.

Agreed.  That's why it doesn't.

The issue is not really with owl:sameAs.  If the mere mention of a URI
reference that is associated with another document is sufficient to import
it, then it would be easy to slurp in much of the semantic web ... which is
quite frightening.  This is why I disagree with those who would like RDF to
work this way.

> Note that I have also found this issue in Topic Map land, where a
> <topicRef> in an XTM file could in theory call another XTM file anywhere on
> the Web, and trigger the same issues (except that Topic Maps can live with
> inconsistencies ...). Nobody ever was able to give me a clear answer about
> it, and I guess nobody has ever really implemented it.

Well this is one of the issues I have with Topic Maps.

> Is this a known issue?

Yes.  I stand on one side; others stand on the other.

> Thanks again for your time
> 
> Bernard
 
peter

Received on Tuesday, 29 April 2003 06:26:03 UTC