On Tue, 24 Oct 2000, Thomas Baker wrote:
> Dear all,
>
> In the flurry of mail before DC-8, Sigge put his finger on an important
> issue (see below), which we should keep in mind as we address the
> "architecture" of DCMI.
You're making my issue deeper than it was intended. What I've been
concerned with has been the naming conventions for the qualified
elements and in particular the human readability of rdf code. And I
know that others are concerned as well.
> Rephrasing the issue in linguistic terms, the
> question is whether:
>
> 1) qualifiers are adjectives modifying nouns
> -- adjectives that can simply be ignored by "dumbing down" a
> statement to just the unmodified noun (i.e., unqualified
> element); or
>
> 2) qualifiers-plus-elements are modified nouns -- inseparable noun-
> phrase units representing, in effect, different nouns. In this
> case, "dumbing down" to the unmodified noun occurs through
> resolving the "is-subproperty-of" relationship between the
> modified noun (qualifier-plus-element, or simply the qualifier
> standing as a shorthand for qualifier-plus-element) and the
> unmodified noun (unqualified element).
I think that we need to keep two things seperate
A. qualifiers and elements as fairly loose concepts and qualifiers
and
B. elements as they appear in any *ML (XML, RDF, SGML etc, even
including other formal syntaxes capable of carrying structured
attributes and values).
To begin with point B, in any syntax (even in HTML syntax
"DC.title.alternative" is in effect an element) a qualified element
has be an element in the *ML sense of that word. Such an element need
not be a metadata element, and this is an obvious source of confusion.
The most current dcq schema says [1]
<!-- Title refinement declarations -->
<rdf:Property rdf:ID = "alternative">
<rdfs:label>Alternative</rdfs:label>
<rdfs:comment>Any form of the title used as a substitute or
alternative to the formal title of the resource.</rdfs:comment>
<rdfs:subPropertyOf
rdf:resource = "http://dublincore.org/2000/03/13-dces#title" />
<rdfs:isDefinedBy rdf:resource = "http://dublincore.org/2000/03/13-dcq" />
</rdf:Property>
Note that comment in fact describes alternative title, an element, not
a qualifier.... I just find it unacceptable that we'll have things like
<rdf:Description about="sigges page">
<dc:title>S. Lundbergs homepage</dc:title>
<dcq:alternative>Sigge's homepage</dcq:alternative>
</rdf:Description>
It is just bad mnemonics. To me alternativetitle, or even
title.alternative would do
<rdf:Property rdf:ID = "title.alternative">
...
<rdfs:subPropertyOf
rdf:resource = "http://dublincore.org/2000/03/13-dces#title" />
...
</rdf:Property>
<rdf:Property rdf:ID = "alternativetitle">
...
<rdfs:subPropertyOf
rdf:resource = "http://dublincore.org/2000/03/13-dces#title" />
...
</rdf:Property>
The former does have some advantages when it comes to transforming
"dotty" metadata to RDF (and the other way around). Although, this
observation perhaps isn't comme il faut, it has not escaped me that
the dumb down path becomes obvious just by inspecting the predicate in
a RDF triple ;)
> Although the two views both support dumb-down, they are different.
>
> -- The view of RDF modelers like Eric and Andy has been #2.
> In this view, adjectives alone can stand for the
> adjective-plus-noun: e.g., an alternative title is coded as
> "<dcq:alternative>Story of my life</dcq:alternative>". The
> process of dumbing down requires a dictionary function (i.e.,
> registry infrastructure) to resolve between the thousands of
> potential modified nouns in the metadata universe -- whether
> they are represented by adjectives-plus-nouns or by adjectives
> alone -- and the fifteen special unmodified nouns of the Dublin
> Core.
>
> -- However, as Sigge points out, #1 offers interesting and
> powerful possibilities as well. For one thing, it would
> allow qualifiers like "alternative" (see Sigge's example
> below) to be used for more than one element without reinventing
> an identical but separate adjective ("alternative") for the two
> separate elements Title and Identifier. It seems more flexible
> linguistically, and does not require us in some cases to
> reinvent -- redundantly -- identical qualifiers in parallel
> for different elements.
>
> I tend to prefer #1, but the weight of RDF practice and the registry
> based on it seem to be pushing us down the path of #2. Does it
> matter? We should in any case recognize the ambiguity and address it
> before we commit ourselves too deeply to #2. At a minimum, perhaps we
> need to distinguish in this regard between element refinements and
> encoding schemes.
>
> Tom
To leave the RDF schema issue, and consider my point A above -- the
conceptual issue how we should define and describe pedagogically what
an element qualifier is.
Traditionally, and in Tom's linguistic view, we have thought qualifiers as
things that when applied to an element gives something else. Any given
qualifier may apply to more than one element. The element refiner
"illustrator" never passed the ballot, but it would apply to both
"creator" and "contributor", depending on the extent the illustrator has
contributed to the resource at hand. As long as we keep the current set of
15 elements, we need to know if an "illustrator" is a contributor or a
creator. It kan not be a subProperty of both. creator.illustrator and
contributor.illustrator works. though. Hmm, I think I'm back to RDF. It
might be that the problem is deeper than I think.
Yours
Sigge
[1] http://dublincore.org/2000/03/13-dcq
-----------------
> On Sep 20, Sigge wrote:
> >In the qualifier recommendation, the "Names" themselves are unfortunately
> >poor, given that their intended use are as RDF/XML tags
> >
> > <dcq:alternative>....</dcq:alternative>
> >
> >doesn't help someone who doesn't know in advance that it refers to
> >alternative title. All of us thought about this as
> >
> > DC.title.alternative
> >
> >To me, this usage is inconsistent. In the latter case the you can see that
> >alternative is a QUALIFIER. In the former it is on its own, still
> >representing the qualified element itself :(
>
> On Sep 21, Sigge wrote:
> >Now, this boils down to a distinction, which we haven't made, the one
> >between the qualified element, and the qualifier. We have to make that
> >distinction and settle how we want HTML metadata and other syntaxes to
> >look like.
> ...
> >The ballot was about qualifiers, not about qualified elements :(
> ...
> >...we haven't made up our minds whether we are describing
> >qualifiers alone, or the correpsonding qualified elements. You suggest
> >that we should do the latter, but we did the former, and I *might* prefer
> >that to the latter (I haven't made up my mind, though). My main point is
> >that we have be aware of what we've done, and adjust our further actions
> >accordinly.
> >
> >I would just like to give a few crazy examples:
> >
> >DC.identifier=http://sigges.own.server.com/my_novel.html
> >DC.identifier.alternative=http://big.mirror.site.org/sigge/sigges_novel.html
> >
> >might be useful to have ;)
> >
> >Perhaps even
> >
> >DC.creator=Mark Twain
> >DC.creator.isVersionOf=Samuel Clemens
> >
> >I don't want to say that these examples above are very good, but I leave
> >them as a proof of concept that our *traditional* way of thinking on
> >qualification is very powerful...
>
> _______________________________________________________________________________
> Dr. Thomas Baker [log in to unmask]
> GMD Library
> Schloss Birlinghoven +49-2241-14-2352
> 53754 Sankt Augustin, Germany fax +49-2241-14-2619
>
>
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
