Supplemental: Re: [osis-core] type on identifier and subject, syntax of content

[Todd Tillinghast]

Patrick, Steve, Chris, and Troy,

To be unambiguous we MUST include a prefix when using type="OSIS",
because without the prefix we will not know the context that identifier
value belongs to.  (May I suggest type="unique" rather than type="OSIS"
for greater clarity.)

When using other type values the prefix would be implied based on the
user documentation or based on a matching <work> value.  (This will
cause software to hard code the values documented in the user
documentation.)

Example:
<identifier type="ISBN">123456789</identifier> will mean that the value
"123456789" is a value in the "ISBN" context.

However if we want to uniquely identify a work by its ISBN number the
type attribute CAN NOT be used.
<identifier type="OSIS">123456789</identifier> leaves context of the
value ambiguous.
<identifier type="OSIS">isbn:123456789</identifier> clearly qualifies
the value.

But why should we have two mechanisms to do the same thing, when one is
ALWAYS unambiguous?  

Why not ONLY use the type attribute to indicate that a value is the
primary identifier for programmatic identification and ALWAYS use a
prefix?  

If it helps we can define a set of enumerated and reserved prefixes that
imply a specific work element for the previously enumerated type values
other than "OSIS".

Proposal:
1) ONLY use "OSIS" (or "unique" in the place of "OSIS") as a type value.
(x- for everything else.)
2) Always include a prefix to qualify the identifier value.
3) Define a set of enumerated and reserved prefixes for the previously
enumerated type values other than "OSIS".

Benefits:
1) Consistency in the use of the type attribute.
2) Consistent mechanism for declaring the SAME identifier when it the
programmatically unique identifier for the <work> and when it isn't.
3) Consistent mechanism with other context qualified identifiers
elsewhere in the schema.

Example:
Always say <identifier>isbn:123456789</identifier> rather than 
<identifier type="ISBN">123456789</identifier> so when you want to use
type="OSIS" you are using the same mechanism to identify the context of
the identifier.

Is there a reason why this in not a more clear, consistent, and
appropriate solution?

Todd
> -----Original Message-----
> From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> Sent: Monday, October 27, 2003 5:35 PM
> To: osis-core@bibletechnologieswg.org
> Subject: Supplemental: Re: [osis-core] type on identifier and subject,
> syntax of content
> 
> Steve,
> 
> After posting Troy's concerns and thinking about it a bit further, I
am
> not sure that we really need my prior suggestion of the prefix.
> 
> If we define type="OSIS" on identifier as being the mechanism that
> allows resolution of osisRefs (see prior post), then why do I need to
> duplicate the value in type as a prefix in identifier (and by
extension
> subject)?
> 
> For example:
> 
> <identifier type="ISBN">ISBN:some_number</idetifier> seems to me to be
> redundant, we already have that information in the type attribute.
> 
> Noting that if someone uses a type that does not appear in the users
> manual, they are required to declare a work element that bears an
> osisWork attribute that matches the type attribute.
> 
> Example:
> 
> <identifier type="pdurusau.org">some_odd_string</identifier>
> 
> and there must be a work element that has "pdurusau.org" as its
osisWork
> attribute.
> 
> Note that Troy reminded me that in osisCore.1.4.1, we did say:
> 
> > One occurrence (and only one) of the &lt;identifier&gt; element
should
> have a type of OSIS.
> 
> Hope everyone is having a great day!
> 
> Patrick
> 
> Steven J. DeRose wrote:
> > I finally read through this thread, and felt pretty lost for a
while.
> >
> > A few things I do feel sure of:
> >
> > * The colon is really ugly if a prefix is standing alone, like in
its
> > declaration.
> >
> > * Using something like "ISBN" as the type of an <identifier> in a
<work>
> > implies no claim to authority over the ISBN namespace, or even the
> > individual ISBN -- no more so that my reading you an ISBN over the
phone
> > or putting it in a bibliography entry.
> >
> > * I think Patrick's solution below for type of ident and subj is ok
--
> > basically leave it open, but we provide a set of recommended values,
and
> > those values are reserved to mean what we say (in other words,
people
> > aren't allowed to say "ISBN" and mean some new scheme they invented
> > instead.
> >
> > * I'm still confused by the meaning of type="OSIS" -- it seems an
odd
> > usage if it's basically a private-use identifier -- would it make
more
> > sense to call what Patrick described below, "Local" or "Private" or
> > "192.168" or something? I'm not going to push hard for that, just
> > throwing it out in case those who actually understand this portion
think
> > it makes sense....
> >
> > At some point I think we should tie this whole system in to URNs
> > somehow; but I haven't studied URNs enough to know what it would
take.
> >
> > S
> >
> > At 3:05 PM -0500 10/27/03, Patrick Durusau wrote:
> >
> >> Greetings!
> >>
> >> Apparently my post concerning the dropping of enumerated types from
> >> identifier and subject got lost in the flood of emails on the
latest
> >> schema.
> >>
> >> Let me make the following suggestion (subject to your comments and
my
> >> getting in contact with Steve):
> >>
> >> Type on identifier and subject should be xs:string.
> >>
> >> Suggested values for the type attribute on identifier and subject
will
> >> be enumerated in the users manual.
> >>
> >> If "OSIS" is used for type on identifier, the value of the
> >> <identifier> element, that is:
> >>
> >> <identifier type="OSIS">The_Part_Right_Here</identifier>
> >>
> >> then the "The_Part_Right_Here" is the identifier for the work
> >> represented by that <work> element for purposes of identifying that
> >> work (whether it is this work or simply a work in the header).
> >>
> >> (Todd's general and continuing objection to this suggestion is
noted.)
> >>
> >> Now, the value to be inside the <identifier> and <subject> elements
is
> >> also unconstrained.
> >>
> >> Note that best practices recommends that such value:
> >> "The_Part_Right_Here" should bear a work prefix, that is to say:
> >>
> >> Work_Prefix:The_Part_Right_Here
> >>
> >> Where the Work_Prefix is defined in a <work> element in the header.
> >>
> >> The Work_Prefix is not required but does allow careful users to
create
> >> OSIS documents that are self-defining in terms of their identifiers
> >> and subjects.
> >>
> >> This suggestion also avoids the use of the "x-" mechanism in favor
of
> >> users defining their work prefixes.
> >>
> >> Does this get a chorus of "+1's?"
> >>
> >> Hope everyone is having a great day!
> >>
> >> Patrick
> >>
> >> --
> >> Patrick Durusau
> >> Director of Research and Development
> >> Society of Biblical Literature
> >> Patrick.Durusau@sbl-site.org
> >> Chair, V1 - Text Processing: Office and Publishing Systems
Interface
> >> Co-Editor, ISO 13250, Topic Maps -- Reference Model
> >>
> >> Topic Maps: Human, not artificial, intelligence at work!
> >>
> >>
> >> _______________________________________________
> >> osis-core mailing list
> >> osis-core@bibletechnologieswg.org
> >> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> >
> >
> >
> 
> 
> --
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> Patrick.Durusau@sbl-site.org
> Chair, V1 - Text Processing: Office and Publishing Systems Interface
> Co-Editor, ISO 13250, Topic Maps -- Reference Model
> 
> Topic Maps: Human, not artificial, intelligence at work!
> 
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core