|
Andy,
I don't wish to get into the debate as to whether or not info URI is a good thing - and the DC-Libraries list is probably not the place to do so - but just to correct an inaccuracy.
It is not in fact true that "info" URIs are designed to be non-dereferencable. [The info URI FAQ is also wrong and out-of-date about this.]
This was the original position taken with INFO. Drafts -00 and -01 said that INFO URIs were not dereferenceable. But following feedback received they realised they could not exclude dereference (only global dereference capability), and admitted that Namespace Authorities could register service mechanisms (e.g. DOI though DX, PubMed though Entrez, etc.) without being bound to those service mechanisms. (Think of them more as "hints".) So the -02, -03, and -04 drafts, and hence the registered scheme all allowed for the disclosure of service mechanisms - aka dereference.
Ann
-------------------------------------------------
Ann Apps. IT Specialist (Research & Development), MIMAS,
The University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039 Fax: +44 (0) 161 275 6040
Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------
> -----Original Message-----
> From: DC-Libraries Working Group [mailto:[log in to unmask]] On
> Behalf Of Andy Powell
> Sent: Wednesday, April 26, 2006 12:43 PM
> To: [log in to unmask]
> Subject: Re: [DC-LIBRARIES] Progressing DC-Lib and MODS
>
> Some time ago I tried putting together a "mixing and matching" FAQ which
> covers some of the issues touched on by this thread. It's currently
> available in the DC Usage Board Wiki area at
>
> http://dublincore.org/usageboardwiki/MixingAndMatchingFAQ
>
> Also, the Guidelines for assigning identifiers to metadata terms
> document at
>
> http://www.ukoln.ac.uk/metadata/dcmi/term-identifier-guidelines/
>
> suggests some possible ways of assigning URIs to metadata terms. I
> think it is worth re-iterating Pete's warning about the use of
> non-dereferencable URIs (or at least the use of URIs for which the
> dereferencing mechanisms are not very widely understood or implemented)
> to identify metadata terms. To quote from the FAQ:
>
> ... it is worth remembering that Semantic Web applications will rely to
> some extent on being able to obtain information about your new metadata
> term, and in particular about its relationships to other terms (see
> questions 4 and 5 below). URI schemes that do not have widely
> understood dereferencing mechanisms should therefore be used with
> caution. For example, "info" URIs cannot be resolved by the majority of
> currently deployed Internet technology (i.e. by using a simple HTTP GET
> request). Indeed, "info" URIs are designed to be non-dereferencable -
> i.e. it is not possible to dereference an "info" URI in order to
> retrieve a representation of the identified resource. Unfortunately,
> this has serious consequences on their utility for identifiying metadata
> terms. If it is not possible to easily obtain a representation of the
> identified term (typically some metadata about the term), then it is not
> possible to obtain any information about the relationships between the
> identified term and other terms. In the context of the Semantic Web,
> this means that the use of "info" URIs may prevent software applications
> from reasoning automatically about your term based on knowledge about
> the relationships between it and other metadata terms.
>
> Andy
> --
> Head of Development, Eduserv Foundation
> http://www.eduserv.org.uk/foundation/
> [log in to unmask]
> +44 (0)1225 474319
>
> > -----Original Message-----
> > From: DC-Libraries Working Group
> > [mailto:[log in to unmask]] On Behalf Of Pete Johnston
> > Sent: 26 April 2006 11:01
> > To: [log in to unmask]
> > Subject: Re: Progressing DC-Lib and MODS
> >
> > Ann Apps wrote:
> > > Thanks Ray and Pete for helpful contributions. Why am I
> > starting to regret volunteering to explain this in language
> > everyone can understand...? Seriously I think this explains
> > it very well - or will when consolidated into a document.
> >
> > I did have a stab at this a while back over at
> >
> > http://www.ukoln.ac.uk/metadata/dcmi/dc-elem-prop/
> >
> > which was a note I prepared for the DCMI Usage Board. But
> > that is a rough draft, and there are some
> > errors/omissions/ambiguities that have been pointed out to me
> > that I haven't had time to go back and correct, so please
> > treat with caution (though I think the main thrust of it is OK)
> >
> > (Time is in short supply just now... but some time soon I
> > will fix up that doc)
> >
> > > But is there an additional issue? XML schema (or DTD)
> > defines the existence and structure of elements according to
> > a known syntax. But it doesn't define semantics for the elements.
> > >
> > > The only semantics I can find for the MODS terms are in the
> > User Guide (I did only look very quickly). This is clearly
> > for human reading.
> >
> > Yes, for the components of an XML format, the "semantics" are
> > always defined in human-readable documentation. XML itself
> > has no "built in semantics" (though maybe the XML Schema
> > primitive datatypes might be considered a move in that direction).
> >
> > I guess I'd qualify that slightly by saying things like GRDDL
> > - a transform to RDF - are another way of making the
> > semantics of an XML format explicit.
> >
> > > The DC-Lib AP itself does define the semantics of the
> > properties as they are used within the AP (currently also for
> > human reading).
> > >
> > > The semantics of DC properties are defined in RDF at
> > > http://dublincore.org/2003/03/24/dces
> > >
> > > Should properties used in a DC Application Profile have
> > defined machine-readable semantics available somewhere as
> > well as URIs (or at least an intention of providing them)?
> >
> > I think it is "good practice" for the owner of the term URI
> > to make descriptions of the term identified by the URI
> > available, so that a user who encounters the URI can obtain
> > information about the term.
> >
> > The use of the http URI scheme for term URIs means that this
> > can be done fairly easily using the machinery of the Web i.e.
> > the owner of the term URI configures their HTTP server so
> > that the term URI can be de-referenced to retrieve a
> > representation of the resource identified by the URI.
> >
> > And HTTP content negotiation even allows an app to request
> > different representations depending on whether it's a browser
> > presenting a doc for human consumption or an application
> > wanting a machine-readable definition - and you can get some
> > additional flexibility out of mechanisms like PURLs.
> >
> > Alistair Miles and Tom Baker and comrades have produced a
> > nice note on this in their work with the W3C Semantic Web
> > Best Practices Group. I think it's still work in progress but see
> >
> > http://www.w3.org/TR/swbp-vocab-pub/
> >
> > Of course, using other URI schemes, other similar mechanisms
> > for obtaining representations of resources may be available,
> > and I'm not really in a position to comment on them.
> >
> > But what I like about the http URI scheme is that I get an
> > awful lot of this functionality more or less "out of the box"
> > i.e. it can be implemented with tools and protocols that I
> > know people are using already.
> >
> > And of course there may be other services that also make
> > information about my terms available. I might go to a
> > "metadata registry" service and say, "Tell me what you know
> > about http://purl.org/dc/elements/1.1/date" and indeed that
> > service might even tell me more than I get by de-referencing
> > the term URI (because it might have aggregated data from
> > several sources).
> >
> > That's "all good", as they say.
> >
> > But it seems to me that making info available "at the term
> > URI" should be the first step for all term owners. If people
> > make the data available through a metadata registry _too_,
> > great. But if they make the data available only in a metadata
> > registry without making it available "at the term URI", then
> > they raise the barrier for the user: the user then has to
> > know not only the term URI, but also the URI of the registry
> > service that can tell them about the term.
> >
> > I think the way this has been phrased sometimes is that we
> > should think of "the Web as the registry", and I strongly
> > agree with that view.
> >
> > Additional services built on top of that by aggregating data
> > are good - not least as they can provide a Google-like
> > discovery function and help me find terms that I didn't know
> > the URI of!
> >
> > But using the Web to serve representations of my resources is
> > nice and easy and extremely helpful (and IMHO we should
> > always do that nice, easy, extremely helpful bit _before_ we
> > start worrying about those richer services).
> >
> > Pete
> > --
> > Pete Johnston
> > Research Officer (Interoperability)
> > UKOLN, University of Bath, Bath BA2 7AY, UK
> > tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
> > mailto:[log in to unmask]
> > http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
> >
|
