(+cc:eric miller)
hi Pat,
On Fri, 12 Oct 2001, Pat Hayes wrote:
> >On Fri, 12 Oct 2001, Peter F. Patel-Schneider wrote:
> >
> >> And just how are RDF applications supposed to determine when to do this
> >> merging?
> >>
> >> peter
> >
> >By using all that DAML+OIL good stuff you've been slaving over, of
> >course :)
> >
> >All DAML+OIL instance data is RDF,
>
> Actually I would say not, though it's only a matter of terminology.
Yes, its a matter of terminology. I'm happy you didn't say branding,
though doubtless that's involved too. But as well, it goes to the heart of
some misunderstandings about the RDF project, about what we've been trying
to do with the RDF and SemWeb effort, and about the relationship between
the RDF core specs and the specs that will join it to flesh out the RDF
family of specifications. For some, "RDF" is just the triples stuff, our
"pipsqueak of a language"; for others, it is this whole (possibly insane)
project of rolling out an (increasingly expressive) framework for
describing stuff in the Web. I'm firmly in the latter camp, perhaps
because my ambitions for RDF have long included the things we're now
calling "Semantic Web" technology, and perhaps because I prefer the phrase
"resource description framework" to our new slogan "Semantic Web". For
one, it lends itself better to nouning: "an RDF file" versus "a Semantic
Web file". It is easier and more informative to say "all DAML+OIL files
are RDF files" than to say "all DAML+OIL files are Semantic Web files"; we
need some umbrella terminology that goes beyond branding to say something
about what all these components (of the description framework) have in
common. For me, they're all RDF, and they all share the intentionally
simplistic RDF worldview of resources, relationships, URIs etc. But I can
see that others are using the acronym differently. I guess it is for W3C
to clear up the confusion; an update to the RDF FAQ is looming, as is the
RDF Core primer.
(anyway, here's my view...)
> It is encoded in RDF syntax, but its meaning isn't specified by RDF.
We still call it RDF. I have some very simple pieces of content, both
instance level and schema (see example below) whose meaning isn't
captured by DAML+OIL. For eg., we may want to use RDF/DAML to talk about
"a util:Document whose dc:title is 'foo' and whose dc:creator is the
foaf:Person whose foaf:mbox is mailto:webmaster@example.com". DAML+OIL
can't distinguish between the cases where (at any one point in time) there
is at most one entity with a given personal mailbox; and the case where
across-all-time that property can only ever have a single value. But RDF
tools, including but not limited to those that understand DAML+OIL, can still do
useful things with this kind of data, even if there are aspects of its
meaning that are not captured in the RDF or DAML+OIL formalisms.
For "its meaning isn't specified by RDF" you may as well say "its meaning
isn't specified by DAML+OIL" in many many cases. So we shrug and admit that yeah
sure, all aspects of meaning are not easily formalised at this stage of
history. And we don't pin this on RDF, nor on DAML, it's just the way
things are: meaning is only partialy captured by the mechanisms we're
playing with here. Despite all this, we need to deploy meaningful
documents in the Web ASAP, without putting everything on hold while we
wait for a formalism that can capture all of that meaning. We need a
framework for getting incrementally better at describing resources in the
Web; that is the 'resource description framework', RDF. The RDF approach
to this has always been to sneak up on the problem bit by bit. The graph
model provides a useful cartoon world view ("objects, types, properties,
relationships; identifiers") that can be shared by more expressive parts
of the system that get designed later. DAML+OIL takes the RDF Schema world
view of classes, properties and constraints, and it adds in a bunch of
richness that reflects into the formalism things that RDF could
previously carry but didn't explicitly acknowledge.
Now my point is just that DAML is in the exact same situation, there are
meaningful constructs that can be carried through DAML without DAML
realising the full meaning. And I'm not talking here about the
reference/naming/denotation aspects of
meaning that I've talked about before, though something similar can be
said about that. Rather, I'm talking about aspects of the meaning of our
content (eg. temporal issue raised below) which one might imagine _are_ in
scope for some fancier Model Theory or Axioms to engage with. Just in DAML 1.x we
don't try. Does this mean that my friend-of-a-friend RDFWeb application,
which uses the property whose URI is 'http://xmlns.com/foaf/0.1/mbox' is
neither an RDF application nor a DAML application but something else yet
to be named. Surely not. Of course there are aspects of meaning, and
specifically the meaning of that property, which neither RDF nor DAML
captures. Nevertheless we can use the Web right now to successfully deploy
and use descriptions of resources in RDF that employ the foaf:mbox
property. Those descriptions don't cease to be RDF because the property is
a particularly interesting one, or because there are rules that one might
(eventually) formalise about its use which can't be written down in a
Semantic Web language yet. That's why we called it a (description)
Framework not a (file) Format: it's a deployment strategy for easing all
this stuff out of research labs and into mainstream Web technology. Slowly
but surely... ;-)
So when I say "all DAML+OIL instance data is RDF data", I mean
(colloqially) that it has basically the same cartoon worldview: of objects
identifiable by URIs, having URI-named classes and URI-named relationships
to one another.
It is of course possible to produce such tangled representations
(encodings of rules, queries etc for example) in RDF that the
object/property/value worldview loses much of its utility. For that matter
I could run something like "tar -c mailbox/* | binhex | gpg --encode >
mail.txt", put that into a literal string in an RDF graph, then go around
claiming that I had an RDF representation of my mailbox. I could, but I'd
be silly rather than wrong. Sure at one level my mailbox is represented
in, or carried through, RDF. It's just a rather useless representation.
Similarly, there are representations-in-RDF (such as the person/mailbox
thing below which (a) draw on aspects of Schema/ontology meaning that are
yet to be formalised and (b) nevertheless make perfect sense as useful
chunks of RDF instance data, couched in the objects/properties/values
cartoon worldview.
> >and RDF apps that are built
> >to know about even a subset of DAML+OIL can make good use of that when
> >doing data merging.
>
> Well, they can if they are DAML-savvy, but then why don't you call
> them DAML apps rather than RDF apps?
>
> >
> >For eg., consider the property http://xmlns.com/foaf/0.1/mbox
> >from the namespace http://xmlns.com/foaf/0.1/
> >
> > [[
> > FOAF is expressed as an RDF Schema, annotated with DAML to express the
> > fact that a foaf:mbox uniquely picks out an individual.
> > ]]
> >
> >Excerpting from that schema:
> >
> > <rdf:Property rdf:about="http://xmlns.com/foaf/0.1/mbox"
> > rdfs:label="Personal Mailbox"
> > rdfs:comment="A web-identifiable Internet mailbox associated
> >with exactly one owner.
> > This property is a 'unique property' in the DAML+OIL sense, in that
> > there is at most one individual that has any particular personal
> > mailbox.">
> >
> > <rdfs:domain rdf:resource="http://xmlns.com/foaf/0.1/Person" />
> > <rdfs:range
> >rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource" />
> > <rdf:type
> >rdf:resource="http://www.daml.org/2001/03/daml+oil#UnambiguousProperty"/>
> > <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/" />
> > </rdf:Property>
> >
> >Since we say the property is of type
> >http://www.daml.org/2001/03/daml+oil#UnambiguousProperty
> >we can use this knowledge in RDF-based applications
>
> How does the RDF application know what the DAML expressions mean?
> (Should it know about all the other extensions to RDF that havnt even
> been invented yet?)
>
> >-- for example merging
> >blank nodes where each node has a property with the exact same resource as
> >its value. In this example, merging nodes that stand for the individual
> >whose presonal mailbox is mailto:foo@example.com, perhaps.
> >
> >Aside: I could complain here that DAML+OIL gives us no mechanism for
> >guaranteeing
> >that the at-most-one-ness remains static in the face of time and change,
> >but that's probably a can of worms best opened in a separate thread.
> >DAML+OIL's "worldview" isn't one that explicitly acknowledges time and
> >change, and there are good reasons for this being the case. How this
> >relates to the need to deploy DAML+OIL ontologies in the Web is something
> >that looms rapidly, imho.
>
> Maybe, but you can hardly pin this on DAML; *nobody* has really
> tackled this issue yet, AFAIK.
It's not a matter of blame, it's a matter of layering. This whole thing
we're building, the graph stuff, the simple schema stuff, the fancier
ontology language, perhaps a rules language... what we're assembling is a
framework for describing resources in the Web. RDF. That picture is only coming
together slowly, and DAML+OIL is a key component. There will be others.
So going back to my original claim that all DAML+OIL instance data is RDF
instance data: what I'm getting at is that to deploy this stuff for real,
on Web sites, in browsers, palm pilots, everywhere, we need some
stability even when the complete resource description framework is not yet
finalised. Maybe the RDF project never will be finalised, but always
pushing to get things out of the lab and into the Web mainstream. I hope
so, fwiw.
The 'description logic meets temporal logic' work is still
in the lab, but please lets not plan to tell the world that there are RDF
instance files, and DAML/OIL/WebOnt instance files, and
WebOnt-PlusTemoralLogic instance files and who knows what follows
after. If and when for example the description-logic-meets-temporal stuff
gets more fully baked, and perhaps submitted to W3C, we'll likely have some way
of annotating my RDF Schema (or Web Ontology) at
http://xmlns.com/foaf/0.1/ to better represent the meaning of the classes
and properties I name there. Does that mean that you'll want me to call my
instance data files something other than "RDF files" (DAML/OIL/Webont
files...). Or maybe they're not even RDF (DAML etc) files today, since the
semantics are not full captured by any Semantic Web schema/ontology/rule
language that I know of. Or we could just worry about something more
interesting than categorising the flavours of instance data, and get used
to calling all this stuff "RDF".
> Pat
Dan