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
|