From: Dan Brickley (Daniel.Brickley@bristol.ac.uk)
Date: 03/03/01
On Fri, 2 Mar 2001, Dan Connolly wrote:
> Dan Brickley wrote:
> > This is a followup to some hallway and lunchtable conversations about
> Regardless of what DAML+OIL+DT does, I consider that practice
> broken. Based on the experience I have building tools and apps,
> I recommend folks get used to making clear distinctions between
> things and names for things.
I appreciate the modelling concern. On other days however we'll argue
that data:* URIs shoe-horn literals into the URI space, so the
distinction between resource-valued and literal-valued properties
doesn't always seem such a fast one. One might also argue that URIs are
also just names (a better kind of name). Given that RDF gives processors
the type of the value of a dc:creator property, the DC data is
fixable. Sometimes it makes sense to adopt a graceful, rich models,
sometimes fixable-hacks make sense. It's not for DAML+OIL or RDF to
police the world's data modelling practices... If consenting adults
decide to exchange dc:creator info the way the dc-datamodel decided
back in spring 1998, it's not for us to pull the infrastructural rug out from
under their feet. I hope and expect to see better practice emerge from DC in
the future though...
> > > I'm
> > worried.
>
> Yes, well, the world is a scary place. ;-)
>
> I agree there's a tension between the things that DAML+OIL+DT
> facilitates and some existing practice, but my mind is clear
> on which should give: the broken practice. Are you suggesting that
> the tension should be resolved some other way? If so, how?
User education, tutorials, tools, good schema guides - sure.
Having RDFS/WebOntology processors catch fire and burn when they don't
like the modelling style - no thanks
>
> I started scribbling
> an RDF modelling best-practices outline the other day:
>
> A) use rdf:type to model unary predicates:
> P(x) becomes rdf:type(x, P)
yup
> B) URIs only go in about/resource attributes; don't put
> them in propAttrs nor propElement content; e.g.
> no: <Book title="alice..." authorHome="../xyz/homePage"/>
> yes: <Book title="alice..."><authorHome resource="../xyz/homePage"/></>
yes
>
> C) choosing a namespace: use #, not / nor ? [not 100% sure about this one,
> but seems wisest at this point]
two concerns here:
(1) this strategy contextualises the meaning of the
named-things: semantics of #foo URI refs are relative to the mime-type
of the bit befoe the #. If the base resource exposes multiple mime-types
(each carrying their own interpretation rules for #) we get into a
muddle. We could get around this by arguing that each namespace has a
'core' mime type prioritised above any others. I've not yet seen that
argument made.
(2) massive schemata.
I've been working with thesauri, medical classification schemes
(UMLS/MesH), and most interestingly WordNet. In each case, we can
project a huge database of terms into the Web. Your proposal works OK
for small vocabularies, but again '#' proves problematic when we have
say 50,000 classes in a single namespace.
Example: I expose (through a grubby hack) wordnet at
xmlns= http://xmlns.com/wordnet/1.6/
eg. http://xmlns.com/wordnet/1.6/Web
http://xmlns.com/wordnet/1.6/Document
http://xmlns.com/wordnet/1.6/Person
...all return fragments of RDFS describing regions of the
namespace. This lets us write <wn:Person> etc in our instance data.
Compare what we'd have if I used #
eg: http://xmlns.com/wordnet1.6#Person
since the URI spec tells us #Person is the local part, if I go fetch
data from the namespace, I have to fetch http://xmlns.com/wordnet1.6
-- what should this get? the 50,000 class RDF/XML dump of WordNet? A
description of a SOAP/XP interface to the remote KB? An RDDL table of
contents? All credible options, but not options I'd like to force on the
entire web community.
> D) things versus their names.
>
> Dublin core is at-risk because of C) as well as D), IMO.
If you believe this, can I ask that you provide a summary of the risk as
you see it that I can get onto the DCMI Architecture agenda as a matter
of urgency. Extra points if you can reference W3C specs that DC's
RDF implementation violates.
cheers,
Dan
This archive was generated by hypermail 2.1.4 : 04/02/02 EST