JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-RDA Archives


DC-RDA Archives

DC-RDA Archives


DC-RDA@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-RDA Home

DC-RDA Home

DC-RDA  February 2012

DC-RDA February 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: The meaning of Subject (and Coverage)

From:

Karen Coyle <[log in to unmask]>

Reply-To:

List for discussion on application profiles and mappings <[log in to unmask]>

Date:

Sat, 25 Feb 2012 14:32:37 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (202 lines)

Thanks, Diane, for the history. It's always hard to understand without 
the subtext of *how* things have come about.

I have no strong interest one way or the other about a solution. But I 
am curious to know what usage of dc:coverage you prefer that would 
return to the

"previous definition (or something new) that does not assume topicality,
 > and perhaps even eschews that usage."

A few examples would probably make things clearest. I realize that you 
gave examples in your post, but without the context it isn't possible to 
know if these eschew the topical usage. (And, yes, I realize that there 
will be a considerable grey area between topical and non-topical, and I 
don't feel a need to disambiguate the whole world, just to see a few 
clear cases, which, then, may be useful in the documentation.)

Thanks,
kc

On 2/25/12 12:00 PM, Diane Hillmann wrote:
> Folks:
>
> As I recall, the change in the definition of 'Coverage' to include
> topicality occurred while I was still on the UB, and I'd like to think I
> spoke against it (though I have no evidence for that, just memory,
> faulty at best). Tom, who probably has to hand all the minutes of those
> meetings might be able to pinpoint the time the decision was made, and
> maybe even the conversations around that change, since he wrote all the
> reports.
>
> That said, I agree with Gordon--the problem is also with the definition
> of Coverage, which says:
>
> Definition:	The spatial or temporal topic of the resource, the spatial
> applicability of the resource, or the jurisdiction under which the
> resource is relevant.
> Comment:	Spatial topic and spatial applicability may be a named place or
> a location specified by its geographic coordinates. Temporal topic may
> be a named period, date, or date range. A jurisdiction may be a named
> administrative entity or a geographic place to which the resource
> applies. Recommended best practice is to use a controlled vocabulary
> such as the Thesaurus of Geographic Names [TGN]. Where appropriate,
> named places or time periods can be used in preference to numeric
> identifiers such as sets of coordinates or date ranges.
>
> /
> /
>
> The Comment reinforces that definition, and its emphasis on topicality.
>
> Then I looked at 'Using Dublin Core'
> (http://dublincore.org/documents/usageguide/elements.shtml) which was
> last updated (by me, probably), in 2005, and it does not mention
> topicality at all:
>
> /Label: Coverage/
>
> /Element Description:/ The extent or scope of the content of the
> resource. Coverage will typically include spatial location (a place name
> or geographic co-ordinates), temporal period (a period label, date, or
> date range) or jurisdiction (such as a named administrative entity).
> Recommended best practice is to select a value from a controlled
> vocabulary (for example, the Thesaurus of Geographic Names [Getty
> Thesaurus of Geographic Names, http://www.
> getty.edu/research/tools/vocabulary/tgn/
> <http://www.getty.edu/research/tools/vocabulary/tgn/>]). Where
> appropriate, named places or time periods should be used in preference
> to numeric identifiers such as sets of co-ordinates or date ranges.
>
> /Guidelines for content creation:/
>
> Whether this element is used for spatial or temporal information, care
> should be taken to provide consistent information that can be
> interpreted by human users, particularly in order to provide
> interoperability in situations where sophisticated geographic or
> time-specific searching is not supported. For most simple applications,
> place names or coverage dates might be most useful. For more complex
> applications, consideration should be given to using an encoding scheme
> that supports appropriate specification of information, such as DCMI
> Period <http://dublincore.org/documents/dcmi-period/>, DCMI Box
> <http://dublincore.org/documents/dcmi-box/> or DCMI Point.
> <http://dublincore.org/documents/dcmi-point/>
>
> /Examples:/
>
>     Coverage="1995-1996"
>     Coverage="Boston, MA"
>     Coverage="17th century"
>     Coverage="Upstate New York"
>
> My [faulty] memory suggests to me that the decision to include
> topicality in Coverage occurred around the time that we added domains
> and ranges, at which time I think we made some adjustments in
> definitions and comments.
>
> As Tom points out, the newer guidelines are likely to follow those
> changes closely (though for the life of me I can't find that document to
> quote from it).
>
> In any case, it seems to me that Gordon's logic is, as usual,
> impeccable, and we should consider specifically returning to the
> previous definition (or something new) that does not assume topicality,
> and perhaps even eschews that usage.  I understand Karen's concerns
> completely (having taught this stuff since the dinosaurs walked the
> earth), and the questions I've answered over the years support her
> contention that people will not find this distinction easy to make, but
> I still think we should make it.
>
> Diane
>
> P.S. I've copied the Vocabulary Management Community list on this, under
> the assumption that they, too, will be interested in how this sausage is
> made.
>
>
> On Sat, Feb 25, 2012 at 2:07 PM, [log in to unmask]
> <mailto:[log in to unmask]> <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>       All
>
>     My first point when discussing this with Tom was that there seems to
>     be an
>     inconsistency in the way dct:coverage is defined.
>
>     dct:coverage and its sub-properties dct:spatial and dct:temporal include
>     the subject aspect of their semantic in the definition. But this is
>     not the
>     case with any other dct attribute. For example, dct:language has
>     definition
>     "A language of the resource.", not "The language topic of the
>     resource, or
>     a language of the resource."
>
>     This is not inconsistent, however, if we propose that the definition of
>     dct:coverage is intended to be entirely subsumed by the definition of
>     subject. That is, "the spatial applicability of the resource, or the
>     jurisdiction under which the resource is relevant" is intended to
>     refer to
>     the topicality or "aboutness" of the resource; the spatial applicability
>     and jurisdiction are assumed to be spatial topics of the resource.
>
>     This appears to be supported by Karen's observation "if your map is
>     coded
>     with geographical coordinates for Berkeley, California, can you consider
>     Berkeley, California the subject of the map? I think many people
>     would." I
>     expect similar arguments to be made for jurisdiction: that the
>     geographical
>     applicability of legislation is "about" that geographical entity.
>
>     This implies:
>
>     dct:coverage rdfs:subPropertyOf dct:subject .
>
>     Then:
>
>     dct:spatial rdfs:subPropertyOf dct:coverage .
>     dct:temporal rdfs:subPropertyOf dct:coverage .
>
>     entails:
>
>     dct:spatial rdfs:subPropertyOf dct:subject .
>     dct:temporal rdfs:subPropertyOf dct:subject .
>
>     But the definitions of dct:spatial ("Spatial characteristics of the
>     resource") and dct:temporal ("Temporal characteristics of the resource")
>     are consistent with dct:language, and we don't generally want to say:
>
>     dct:language rdfs:subProperty dct:subject .
>
>     A document in a written language is not "about" that language, etc.
>
>     This tends to suggest that the proposition that dct:coverage is a
>     sub-property of dct:subject by virtue of its intended (but possibly
>     unclear) definition is incorrect. That is, dct:coverage has a scope
>     beyond
>     "aboutness".
>
>     This results in a problem for applications requiring an index of all
>     subjects/topics "about" a resource. A subject index needs to cover the
>     objects of triples using dct:coverage, dct:spatial, and dct:temporal, as
>     well as dct:subject, and will thus include values which are not
>     "about" the
>     resource (i.e. false drops).
>
>     And the same problem will arise when mapping elements from other
>     bibliographic namespaces to dct.
>
>     Cheers
>
>     Gordon
>
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
August 2012
July 2012
May 2012
April 2012
March 2012
February 2012
January 2012
October 2011
September 2011
August 2011
June 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
February 2010
January 2010
December 2009
November 2009
October 2009
June 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
August 2007
July 2007
June 2007
May 2007
April 2006
February 2006
January 2006
December 2005


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager