Tom, perhaps we have a simple answer to this problem.
The term "literal" is one of long-standing in language, and of common
use in the computer world. It is a useful term for talking about
certain concepts.
DCAM has created a concept that it calls "literal" that in fact
provides a different definition for the term. So different that it
perhaps should have had a unique identity to distinguish it from the
broader and more common use of "literal." (Try "define:literal" in
Google. None of the meanings are the DCAM meaning.) Since the vast
majority of uses of the term will NOT be intended to have the meaning
assigned by DCAM (even on DC lists), it would be good to clearly
identify when the DCAM use is intended. There are various ways to do
this; something like "DCAM:literal" might work. That would alert the
reader that the intended meaning is not the dictionary meaning, but a
reference to a specific technology.
If we follow this, then persons using the term with its commonly
accepted meaning will not be corrected for not using the DCAM term,
which most likely they did not intend in the first place. After all,
DCAM cannot redefine the word for others -- it's a perfectly good
word, and people have a right to continue using it.
So if you say: "the difference between "non-literal" and "literal"
values is not the difference between URIs and strings..." I would
disagree with you. But if you say:
"the difference between DCAM:non-literal and DCAM:literal values is
not the difference between URIs and strings..." I would agree.
Context is important, and I believe that the assumption that DCAM is
ALWAYS the context in our discussions is not only not true, but is a
hindrance to communication. I don't want to be forbidden from talking
about "literals" in the common sense of the term; I may need to talk
about them. I may want to talk about them. But constantly being
corrected for using my own language in its normal way is discouraging
and makes me not want to participate in this discussion. I imagine
that others have had the same experience.
At this point I have to say that I wish DCAM would just die. It has
been more of a hindrance than help, so far. If you could use it for
good rather than for berating people, you might get further.
Sorry for the bad mood.
kc
On Fri, Nov 28, 2008 at 6:26 AM, Thomas Baker <[log in to unmask]> wrote:
> Karen,
>
> I want to briefly pick up a discussion thread from August
> about on the somewhat difficult distinction between "literal"
> and "non-literal" values which, on re-reading, I think could
> be more fully explained.
>
> On 14 August, Karen Arcamonte wrote:
>> I'm currently involved in the selection of standard fields for a metadata
>> project and we have some fields that we are calling Dublin Core fields
>> (Subject and Relation fields), but we are including free text or
>> uncontrolled terms. I notice that the DC Subject and Relation fields are
>> "intended to be used with a non-literal value." I'm not sure what this
>> means. Is there anyone that can explain in simple terms? I've looked at the
>> DCMI Abstract Model and I'm still not sure what they mean by "non-literal"
>> value.
>
> And on 18 August, Karen concluded:
>> Thank you all for your comments, I will be looking at many of the links you
>> provided as time permits....I'm concluding that it is okay to include a
>> literal string in a DC Subject field even though a non-literal would be
>> better (or best practice).
>
> The conclusion is correct inasmuch a value string can in
> fact be correctly used with DC Subject (dcterms:subject),
> and it is also true that for various reasons good practice
> is shifting towards using URIs to identify subjects.
>
> However, the difference between "non-literal" and "literal"
> values is not the difference between URIs and strings. To
> quote the latest draft "Guidelines for Application Profiles",
> Appendix C:
>
> Note that the difference between literal-range
> and non-literal-range properties is primarily a
> modeling issue. The type of property determines how
> the metadata will be encoded machine-processably
> for exchange and interpreted by applications that
> consume the metadata. End-users need not necessarily
> see the difference. When displayed in a search result,
> a value string looks the same regardless of whether it
> is directly a literal value or a value string attached
> to a non-literal value.
>
> In other words, it is _always_ permissible to use a value
> string with _any_ Dublin Core property, even the ones intended
> to be used with "non-literal" values. What the literal or
> non-literal range determines is how those value strings are
> contextualized in the data when exposed as open linked data
> (i.e., as RDF triples).
>
> To return to Karen's question above, if DC Subject is intended
> to be used in your project _only_ with value strings, then
> it would pose no problem to expose those strings correctly
> in RDF (for example, in order to merge that data with other
> data sources). A problem would arise only if DC Subject were
> intended to be used either with value strings _or_ with URIs,
> _and_ the local encoding syntax were not to differentiate
> between the value strings and the URIs. See Appendix C of
> the Guidelines draft [1] for a more detailed explanation...
>
> The "literal"/"non-literal" distinction first becomes
> relevant when looking beyond the context of a locally defined
> application towards interoperability in a broader, linked-data
> context -- Level 2, "formal semantic interoperability", as
> described in the draft "Interoperability Levels for Dublin
> Core Metadata" [2].
>
> Tom
>
> [1] http://dublincore.org/documents/2008/11/03/profile-guidelines/#appc
> [2] http://dublincore.org/documents/2008/11/03/interoperability-levels/
>
> --
> Dr. Thomas Baker <[log in to unmask]>
> Director, Specifications and Documentation
> Dublin Core Metadata Initiative
>
--
-- ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
|