Mostly 'what Jane said'. Mixed-namespace web data applications have been
around since XML. The critical technology here was XML's rather
revolutionary distinction between being 'well formed' data versus the
good old-fashioned SGML notion of 'valid with respect to one DTD'. The
addition of URI-based vocabulary naming (XML namespaces / RDF) gives us
all the basis for vocab mixing. The term "application profiles" seems to
be being used to describe our desire for richer ways of characterising
our pick'n'mix attitude to namespace mixing. There will always be
multiple approaches to schema definition, and these will offer varying
facilities for describing mixed namespace use. That's good and healthy.
Schematron (an XSLT-based approach to XML schema,
http://www.ascc.net/xml/resource/schematron/schematron.html) is
interesting in that it makes rather explicit something that I think
we've all known all along: How you use an XML/RDF vocabulary (ie. usage
constraints in various contexts) isn't necessarily something that's an
intrinsic property of the vocabulary itself. For eg., nothing about
dc:title either rules in or rules out the fact that I might decide, for
some computer application, database, whatever, to say "I want exactly
one dc:title in this context, and it should end in a full stop." That
kind of constraint isn't (contrary to the DTD approach) intrinsic to
dc:title itself; rather, it's contextual to my use of dc:title.
IMHO we'll get richer application profile machinery as and when we get
richer query facilities over our mixed-vocabulary Web data. I claim this by
analogy with Schematron's use of XPath expressions for writing down
rules about the desired properties of XML documents. We can do just the same
thing in RDF w.r.t. RDF data structures once we've a query language that
lets us express constraints/rules over RDF information models. Application
profiles, again, are simply about characterising metadata use. We want
to be able to write a chunk of data that expresses (say) our wish that
-- in some context -- a website description must have exactly one title,
one or more quality ratings, an IMS:foo educational category, at most
one DC:description and an rss:channel URI. Fortunately, such a claim is
the sort of thing that will be expressible in any query formalism worth
adopting for RDF. While there are some features in XML Schema, RDF
Schema, Schematron, Relax, DTDs are various other systems that help one
express such constraints, I don't think we're totally there yet. But
I agree with Jane that this isn't a strange new world, but a fairly
familiar problem that's become (for many good reasons) rather topical.
Dan
On Sat, 19 Aug 2000, Jane Hunter wrote:
> Hi Carl,
>
> My point is that I don't see how an application profile is any different from a
> schema which imports elements from existing community-defined namespaces or
> other schemas? This functionality has been available for a while and so far
> noone has been able to point out to me how 'application profiles' introduce
> anything new or different.
>
> jane
>
> > > -----Original Message-----
> > > From: Jane Hunter [mailto:[log in to unmask]]
> > > Sent: Wednesday, August 16, 2000 8:06 AM
> > > To: Carl Lagoze
> > > Cc: [log in to unmask]; [log in to unmask]
> > > Subject: Re: Applications profiles
> > >
> > >
> > > Dear Carl, Rachel,
> > >
> > > I agree with Carl's assertion that neither approach is the
> > > only correct one.
> > >
> >
> > >
> > > The other point I want to make with this example is that
> > > given schemas such as
> > > the one above, I really don't understand the necessity for
> > > calling it an
> > > 'application profile'. Given people's tendency to want to do
> > > their own thing,
> > > there could potentially be an infinite number of these
> > > schemas and as long as
> > > the schema definition which goes with a particular
> > > description is provided
> > > somewhere then interoperability is provided, without
> > > registering it as an
> > > 'application profile'. Unless I'm missing the point of
> > > application profiles?
> >
> > Hi Jane,
> >
> > I think that there is one point that your are missing here that may
> > clear up your question. That is the magic i-word, interoperability,
> > that is the supposed basis of all of this. If we restrict the purpose
> > of metadata to resource discovery for the purpose of this discussion,
> > the reason for a community adopting some well-defined group of elements
> > is to allow common queries over those elements on the content in the
> > domain of the participants in that community(in the simplest terms for
> > putting up a user interface with a bunch of text boxes corresponding to
> > those elements). Let's for the sake of convenience call those
> > well-defined group of elements a "record". DCMI has never defined a
> > closed record format for the DCES, preferring to keep the everything
> > optional, everything repeatable principle. The idea, as I understand
> > it, is to allow communities to create "profiles" that use selected
> > elements with contraints that correspond to the communities needs. As
> > Rachel points out in her paper, and as others have noted, a good number
> > of communities will require a record format that includes semantics
> > outside the bounds of DCES sementics. Thus, the notion of the
> > application profile abstraction, which accepts the fact that in a number
> > of cases a community may want elements that do exactly fit into those
> > defined within DCES but also accepts the fact that the "records" needed
> > by these communities will require elements from other namespaces.
> >
> > This, as a matter of fact, is exactly the type of situation as we
> > re-consider our "core metadata set" for the
> > (http://www.openarchives.org). We need an element that expresses simple
> > "title" semantics, and we might as well use the title element from the
> > DC namespace for this. We also need another element with meaning
> > "miscellaneous comments about this entry" which doesn't fit cleanly into
> > the DCES namespace, so we plan to mix that in our application profile.
> >
> > In this context, however, the problem I raised earlier exists. We want
> > more expressive "creator semantics" including affiliation which doesn't
> > match the semantics of the DC "creator" element. So, do we have a DC
> > creator element that co-exists with a more expressive OAI creator
> > element?
> >
> > Carl
> >
> > However, we also have the same problem I raised earlier.
> >
> > >
> > > jane
> > >
> > > +----------------------------------+--------------------------
> > > -------------+
> > > | Dr Jane Hunter | Senior Research
> > > Scientist |
> > > | DSTC Pty Ltd | Distributed Systems
> > > Technology CRC |
> > > | Level 7, General Purpose South | Tel : +61 7 3365 4310
> > > |
> > > | The University of Queensland | Fax : +61 7 3365 4311
> > > |
> > > | Queensland 4072, Australia | Email : [log in to unmask]
> > > |
> > > +----------------------------------+--------------------------
> > > -------------+
> > >
> > > > Rachel,
> > > >
> > > > Thanks for circulating your position paper on applications
> > > profiles [1].
> > > > I read it with interest and think that it raises a number
> > > of interesting
> > > > issues that need to be raised in the context of DCMI. Put
> > > together with
> > > > Tom Baker's grammar paper [2] and my simplicity and
> > > complexity paper [3]
> > > > it opens up an interesting context for conversations. To
> > > start the ball
> > > > rolling here is my perception of areas of agreement and possible
> > > > disagreement.....
> > > >
> > > > No surprise that we all agree that DCES is not a "complete metadata
> > > > solution". Rather, as formulated since DC2 at Warwick,
> > > DCES defines one
> > > > set of metadata semantics that will coexist with other
> > > role, purpose,
> > > > community, etc. metadata 'packages'.
> > > >
> > > > If I read your proposal correctly, my impression is that
> > > you formulate a
> > > > metadata architecture whereby DC elements (e.g., creator) will be
> > > > intermixed with other community/application specific elements (from
> > > > separate namespaces). Such intermixing implies a 'building block'
> > > > approach to creating metadata descriptions. While such an approach
> > > > might seem appealing I find it possibly inconsistent with
> > > some of the
> > > > thinking about DC 'statements' as described in Tom's paper [2].
> > > >
> > > > As stated by Tom in [2], DCES is essentially a metadata
> > > pidgin that can
> > > > express sets of statements of quite limited nature - i.e. the
> > > > limitations of qualification and the notion of an
> > > 'appropriate literal'.
> > > > Given this, the use of DC elements in an application
> > > profilie would be
> > > > rather restrictive. For example, I could use DC:CREATOR
> > > element for
> > > > only the purpose of providing a name. However, as is well know many
> > > > communities wish to describe the entities that are included in DCES
> > > > semantics in a much richer fashion; e.g., the many
> > > discussion we have
> > > > had about agent attributes and the agent core issues. I'm
> > > confused then
> > > > about how one would use applications profiles in such a
> > > context. Would
> > > > I have parallel elements using something like DC:CREATOR
> > > for a simple
> > > > name and than elements from another namespace for a more
> > > complex creator
> > > > description (e.g., the sort of thing that vcard does) that would
> > > > probably also include and duplicate the creator name? The creator
> > > > element is not the only one where this problem arises.The
> > > potential for
> > > > such parallelism and overlap exists with other DC elements,
> > > since many
> > > > communities want more complex descriptions for many of the entities
> > > > implied by DC elements. It appears that rather than ending
> > > up with nice
> > > > neat building blocks as shown in your position paper, we
> > > could end up
> > > > with some messy descriptions with elements from different namespaces
> > > > that overlap each other and duplicate bits of information.
> > > >
> > > > Perhaps a more workable solution is not to think of DCES as
> > > one building
> > > > block in putting together a metadata description, but to think of it
> > > > (and other metadata descriptions) as views or perspectives into more
> > > > complex descriptive frameworks. The DCES view could then
> > > co-exist with
> > > > other views that conform to different application and
> > > community specific
> > > > needs. With developing technologies such as SOAP [4] or in a
> > > > architecture such as FEDORA [5] that we've created at
> > > Cornell, it would
> > > > be possible to for clients to request a metadata view that
> > > matched the
> > > > clients needs and for the such view to be derived from some more
> > > > descriptive framework (such as the event based model stated
> > > in [3] and
> > > > [6]). (This corresponds to Tom Baker's assertion that DCES is not
> > > > necessarily a record format but 'pidgin speak' for richer
> > > descriptive
> > > > semantics). Such a model would allow DCES to fulfill its
> > > very important
> > > > role as a model for interchange of simple cross-domain resource
> > > > discovery metadata, without trying to mix it in perhaps
> > > messy ways with
> > > > more complex descriptive semantics.
> > > >
> > > > Again, thanks for the position paper and its great to see us in DCMI
> > > > start to move beyond discussions of just the 15 elements. I make no
> > > > assertion here that your solution is 'wrong' and mine is
> > > 'right'. Both
> > > > have issues that need to be discussed and I look forward to
> > > community
> > > > moving forward on these.
> > > >
> > > > Carl
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [1] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0000.html
> > > > [2] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0016.html
> > > > [3] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0018.html
> > > > [4] http://www.develop.com/soap/
> > > > [5] http://www.cs.cornell.edu/cdlrg/FEDORA.html
> > > > [6]
> > > >
> > > http://www.ncstrl.org/Dienst/UI/1.0/Display/ncstrl.cornell/TR2000-1800
> > > >
> > > >
> > > --------------------------------------------------------------
> > > ----------
> > > > ----
> > > > Carl Lagoze, Digital Library Scientist
> > > > Department of Computer Science, Cornell University
> > > > Ithaca, NY 14853 USA
> > > > Phone: +1-607-255-6046
> > > > FAX: +1-607-255-4428
> > > > E-Mail: [log in to unmask]
> > > > WWW: http://www.cs.cornell.edu/lagoze/lagoze.html
> > > >
> > >
> > >
> > >
>
>
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
