Re: [Scrollkeeper-devel] URN as identifier

[Kendall C. <ke...@mo...>]

>>>>> "bob" == Bob Stayton <bo...@sc...> writes:

  >> Right.  So I guess the URN would go in identifier.  This can be
  >> done without any modification to the OMF I believe.  (Is a URN
  >> considered a URL?  If not, I guess we should explicitly state
  >> that an identifier may be a URN.)

  bob> Well, if you look at the OMF template at
  bob> http://www.ibiblio.org/osrt/omf/cgi-bin/template.pl the
  bob> <identifier> element says "(e.g. a URL or URN)".  The DTD uses
  bob> "url" as the attribute name, but I believe that should be
  bob> interpeted as a more general URI.

I worked on OMF so let me see if I can remember some good answers to
these better questions.

As for "more general URI": yes, exactly. I wasn't being careful to
distinguish URN from URI and URL in the DTD, as I should have been. I
suspect that attribute should be renamed "URI" -- at least, that's
what I'd name it today if I were working on the DTD now.

  bob> This sounds fine, but I'm trying to understand the OMF syntax
  bob> for these.  As I read the existing OMF specification for
  bob> VERSION, it has modifiers VERSION.identifier, VERSION.date, and
  bob> VERSION.description.  The description calls these attributes.

I haven't followed very closely the Scrollkeeper discussion recently,
so if this is wide of the mark, someone please correct me. But the OMF
VERSION.(identifier, date, description) was meant to be used to store
versioning, as in RCS/CVS, metadata about resources. So the three
parts -- id, desc, date -- were intended to be used thus (in
pseudo-markup):

<version id="1.0" desc="The initial public release" date="20010101" />

Again, I haven't followed the SK conversation, so I don't know if you
all are talking about using VERSION for revision metadata or for
something else.

  bob> But the OMF DTD defines them as child elements of <version>.  I
  bob> guess the spec uses the word "attribute" in the general
  bob> meaning, not in the XML DTD meaning.

Yes, in general the spec is *not* using words in their XML or SGML DTD
sense, since the spec was written before any DTD was begun, and by
people who did not have DTD jargon primarily in mind. This is
appropriate since the OMF spec could be used equally well as the basis
of an XML Schemas, TREX, RELAX, or Schematron formalization effort.

Again, if I recall correctly, I made id-desc-date child elements of
VERSION primarily out an urge to avoid tying the hands of users of
OMF. Description, for example, may well be anything from a short
sentence to paragraphs of information, a la CHANGELOG.

  bob> If seriesid and identifier are children elements of <relation>,
  bob> I'm not clear on how the <relation> XML attributes are used.
  bob> Perhaps we should contact someone at OMF to get clarification
  bob> on the expected usage of <relation>?

The ambiguity of OMF's RELATION pretty faithfully mirrors the
ambiguity, at the time, of Dublin Core's use of RELATION. That is,
it's vague on purpose, in a kind of librarian, infosci, you just never
know sense. :>

What we need, and maybe Dublin Core has made some progress on this, is
a way to specify the *type* of RELATION; that is, a controlled
vocabulary that gives us a way to specify kinds of RELATION between
resources. SK doesn't necessarily need to rely on a controlled
vocabulary from another organization in this regard; if Dublin Core
has released one by now, there's no reason to think that it will
necessarily be useful in the SK effort. The SK team is perfectly able
to define it's own controlled vocabulary for kinds of RELATION, given
its problem domain; make it public, maintain it in a clear and open
fashion, and, perhaps most importantly, make sure that who or whatever
is generating SK content is amenable to using it.

I hope some of this helps. (FWIW, I've been mulling a rewrite of the
OMF DTD using James Clark's new TREX schema specification language,
which is now Linuxly-viable given that it has an initial Python
implementation. But I need to catch up to the SK status quo to see if
that makes less sense than any of a number of alternatives.)

Best,
Kendall Clark
-- 
I am a finite state machine.