Karen,
On Fri, Nov 28, 2008 at 11:03:29AM -0800, Karen Coyle wrote:
> So, Pete and Tom, if rather than "literal" Irwin and I had talked
> about "character strings" would that have made the concepts more in
> keeping with your division of literal and non-literal?
Basically yes. We are stumbling over exactly how to say things
because we are subtly confusing how the underlying data is
represented for machine processing with the how the data looks
to the user who "fills in the fields" to create that data.
The literal value / non-literal value distinction has to do
with how the data is modeled and would therefore be represented
as machine-processable, linked data.
Looking not at the underlying data model but only at the "fields"
presented to be filled in by a describer, then yes, a value string
may be used in the context of a non-literal value.
> Because I do
> think that the common use of the term "literal" (rather than the RDF
> and especially the DCMI use) is that of "string."
Well, it is used that way in DCMI usage too: in the DCMI
Abstract Model, a "value string" is a literal: "A literal,
optionally associated with either a syntax encoding scheme
URI or a value string language."
http://dublincore.org/documents/abstract-model/#sect-7
But careful: a "literal" is not the same as a "literal value"...
> I interpreted
> Irwin's question to be about the use of strings in the field. (Perhaps
> incorrectly, but he can speak up on that.) And that what you have both
> said (if you have said the same thing, which I'm not sure of) is that
> when a property is defined as a non-literal you can use URIs or
> strings as values.
Almost... You are using "value" above in the common-sense
understanding of "the thing entered in the field", which
subtly clashes with the use of "value" as an entity in the
underlying data model.
Substitute the last two words ("as values") with "in describing
the value", and we can avoid the confusing jargon clash, i.e.:
when a property is defined as having a non-literal range,
you can use URIs and/or strings in describing the value.
I think we need to have a sense of humor about this... :-)
It may seem like splitting hairs from a practical point of
view -- because in either case, one may be presented with a
blank to be filled in with a character string -- but there
are important underlying differences in how the data is
encoded or represented for purposes of interoperability.
> And although it may be preferred to use a value
> list, it is not necessary. So if Irwin chooses not to use URIs or a
> controlled list of values, can he still use dcterms:language in his
> metadata?
Yes, that is correct. He can write "German" or "French" into
the field as a character string and doesn't have to use a URI
or identify a controlled list of values.
What he doesn't see (unless he examines the underlying data)
is that this string is being presented for use in machine
processing according to the "non-literal value" pattern.
This is something that does need to be taken into account in
the process of designing the metadata.
Tom
>
> kc
>
> On Fri, Nov 28, 2008 at 9:19 AM, Pete Johnston
> <[log in to unmask]> wrote:
> > Hi Karen,
> >
> >> My understanding of 'non-literal' is that it does not exclude
> >> the use of literal values; instead it can allow either
> >> literal or non-literal, so it is the broadest of value
> >> possibilities.
> >
> > Ah, careful :-) No, I'm afraid that's not the case: the class of
> > "non-literals" does exclude "literals".
> >
> > Some properties e.g. the 15 DCMES properties, are defined so as to allow
> > their use with either literal or non-literal values. And the DSP model
> > includes - in section 6.3 - the option of not specifying that the value
> > must be a literal or must be a non-literal; in fact, that is the
> > default. Using this default option means that in, an individual
> > statement, either a literal or a non-literal is permitted. But when that
> > default option is used, no further constraints on the value surrogate
> > can be specified in the statement template.
> >
> > Also what the DCAM calls a "value string" can be provided in each case,
> > but that is not the same thing as saying that the set of non-literals
> > includes the set of literals.
> >
> >> Not knowing exactly what you had in mind for
> >> literal language values, one could enter "English"
> >> "French" or "German" into a property defined as
> >> dcterms:language. If the terms themselves are controlled in
> >> some way (e.g. you have a fixed
> >> list) then you are entering non-literal values, and you will
> >> define that list in your description profile. If not, if the
> >> content is absolutely wide open, then you are entering
> >> literal values, even though the property is defined as non-literal.
> >
> > The literal v non-literal distinction is a separate one from the
> > controlled list v uncontrolled/"wide open" one. One can have a wide open
> > set of non-literals and a controlled list of literals.
> >
> >> If what I say above is correct, then one could remove the
> >> list requirement from the description of our language
> >> property and go from:
> >>
> >> Statement template: language
> >> minimum = 0; maximum = 3
> >> Property: http://purl.org/dc/terms/language
> >> Type of Value = "non-literal"
> >> takes list = yes
> >> Syntax Encoding Scheme URI =
> >> http://purl.org/dc/terms/ISO639-2
> >>
> >> to
> >>
> >> Statement template: language
> >> minimum = 0; maximum = 3
> >> Property: http://purl.org/dc/terms/language
> >> Type of Value = "non-literal"
> >
> > You could certainly have a statement template of this second form, which
> > omits the specification of a syntax encoding scheme, but the fact that
> > it says type of value = non-literal means that that template permits
> > only non-literal values (and not literal values).
> >
> > To go back to Irwin's initial question the reason for specifying that
> > values are non-literals is that (as I see Tom has just said) DCMI chose
> > to specify that the dcterms:language property should be used with
> > non-literal values (or at lesat that is the intent, even if the formal
> > description of the term isn't as specific about that point as it might
> > be). And that is a "global" consideration, which should be respected in
> > the construction of constraints which are specific to a DSP.
> >
> >> Because there is no list named, it will not be possible to do
> >> any automated quality control on the values (e.g. checking
> >> the values against the list of valid values).
> >>
> >> It would also be possible to include an ad hoc list in the
> >> statement template. So if you want to limit your set of
> >> languages to the three I gave above, you could code those in
> >> your DSP. (I had an example at one time but can't put my
> >> fingers on it at the moment. We have talked about creating
> >> some 'design patterns' to illustrate common description
> >> types.)
> >
> > Pete
> >
> > ---
> > Pete Johnston
> > Technical Researcher, Eduserv Foundation
> > [log in to unmask]
> > +44 (0)1225 474323
> > http://www.eduserv.org.uk/foundation/
> > http://efoundations.typepad.com/efoundations/
> >
>
>
>
> --
> -- ---
> Karen Coyle / Digital Library Consultant
> [log in to unmask] http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> mo.: 510-435-8234
> ------------------------------------
--
Dr. Thomas Baker <[log in to unmask]>
Director, Specifications and Documentation
Dublin Core Metadata Initiative
|