RE: SemWeb terminology page

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Karen Coyle
> Sent: Saturday, December 04, 2010 7:16 AM
> To: public-lld
> Subject: Re: SemWeb terminology page
> 
> Quoting Antoine Isaac <aisaac@few.vu.nl>:
> 
> > Hello Karen,
> >
> > Would that definition of Svenonius be compatible with the view in
> [1]?
> 
> I don't believe it is, which is why I posted it here. This definition
> has also helped me think about the models developed by FRAD and FRSAD,
> which both have an entity for the authoritative term itself. (And this
> relates to the post I forwarded about MADS.) A primary purpose of
> library authority data is to control the text string itself as a
> surrogate for the thing it represents. This is in addition to
> developing an identity for the thing. (I'm not saying this is *right*,
> I'm just saying this is what libraries claim to be doing.)

Is the "text string" or the "authority record" the surrogate? Here's my
guess:

Early library models used text strings as "controlled access points". As
Karen implies, we probably believed the "text string" was "the
surrogate". Authority records came along with opaque identifiers and
before we knew it the "text strings" in them started changing over time.
We reluctantly resigned ourselves to thinking of the authority record as
"the surrogate". (Idealized immutable "controlled access points" still
seem to haunt our thinking.)

In a Linked Data context, the idea of surrogate appears to be outmoded.
Distributed agents are able to identify "the thing" directly without
reference through a surrogate. Like Karen, I assume librarians will be
concerned that the ideal of immutable "controlled access point" is being
pushed even further away by further demotion from "established heading"
to mere "preferred label".

Does that sound like a plausible account?

> I think it is easiest to see this in terms of subject (concept)
> authorities. The concepts have relationships to each other, such as
> broader and narrower. Those can be modeled with URIs that represent
> the concepts. Each concept, however, also has one authoritative
> expression in "natural" language. In the library sense of controlled
> vocabulary, those terms identify the concept for the user and control
> the interaction between the library data and the library (human) user.
> 
> One thing that may undermine the library emphasis on controlling
> actual language terms is that these terms are allowed to change (after
> careful and lengthy deliberation :-)). In this sense they do seem to
> me to be a kind of prefLabel rather than an actual identifier (because
> when you change an identifier you have a different thing; when you
> change a label the thing has not changed).
> 
> Now the question is: is skos:prefLabel = controlled vocabulary term?

I wouldn't call it a "controlled vocabulary" unless skos:inScheme was
also involved.

> The MADS in RDF creates madsrdf:authoritativeLabel, presumably because
> skos:prefLabel was not considered adequate to express this. In a sense
> this becomes a question about SKOS and the meaning of prefLabel.
> 
> If skos:prefLabel had been named skos:authorityLabel, I think
> librarians would be more willing to use it. "Authority" is a stronger
> concept than "preference." 

Does the additional requirement of using skos:inScheme for "controlled
vocabularies" that use skos/xl:prefLabel help resolve this concern for
you? 

The concern may be that anyone can create a skos:ConceptScheme, but
libraries may want to create a subclass they consider to be "authority".
The new VIAF ontology does this with its viaf:AuthorityScheme class.
(Unfortunately, the VIAF ontology is virtually unusable by humans
because of stylesheet problems. Sorry.)

http://viaf.org/ontology/1.1/viafOntology.owl

Here's the relevant snippet, though:

<owl:Class rdf:about="http://viaf.org/ontology/1.1/#AuthorityScheme">
	<rdfs:subClassOf
rdf:resource="http://www.w3.org/2004/02/skos/core#ConceptScheme" />
	<owl:oneOf rdf:parseType="Collection">
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/BAV" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/BNE" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/BNF" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/DNB" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/EGAXA" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/ICCU" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/JPG" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/LAC" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/LC" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NKC" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NLA" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NLIara" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NLIcyr" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NLIheb" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NLIlat" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NSZL" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/NUKAT" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/PTBNP" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/RERO" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/SELIBR" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/SWNL" />
		<viaf:AuthorityScheme
rdf:about="http://viaf.org/authorityScheme/VIAF" />
	</owl:oneOf>
</owl:Class>	

> But in the end I think that the library
> emphasis on terminology is an artifact of past technologies. I
> consider the library practice to be out-dated, but I note that the
> practice is being carried forward into RDF and LD representations.

I think there are still important use cases for treating terms as
first-class objects (e.g. attaching pronunciation). Nevertheless, we
need to acknowledge the mutability of naming things (e.g. people and
concepts) by modeling names/labels/terms as properties of a relatively
immutable "primary entity" (as the UNIMARC Authority format calls them).

Jeff

> 
> So.... I would like to hear Marcia's take on this from the FRSAD
> "thema, nomen" point of view.
> 
> kc
> 
> > I have the feeling that yes: reference datasets in LD still control
> > the terminology, even if in the LD case the importance of "terms"
> > becomes secondary to the one of the resources that these terms refer
> > to. But I'm really curious to hear from you (and others of course
> > :-) ) on this.
> >
> > Antoine
> >
> > [1] http://lists.w3.org/Archives/Public/public-lld/2010Dec/0029.html
> >
> >
> >> In her book "The intellectual foundation of information
> >> organization" Svenonius has a section on controlled and
> >> uncontrolled vocabularies. Her statement about controlled
> >> vocabularies says:
> >>
> >> "[Controlled vocabularies] are constructs in an artificial
> >> language; their purpose is to map users' vocabulary to a
> >> standardized vocabulary and to bring like information together."
> >> (p.88) [1]
> >>
> >> Do we agree that this is the role of our #1 group? I ask because I
> >> perceive this to be different from the original proposed
definition:
> >>
> >> "These describe concepts that are used in actual metadata."
> >>
> >> If you look at FRAD [2] you see that the assignment of terminology
> >> to the concept is of equal or greater importance than any
> >> description of the concept itself. In fact, that's what I would
> >> emphasize as the role of a controlled vocabulary: that it is a
> >> method to *control* *language terms*. Many controlled vocabularies
> >> have minimal information about the concepts, but all exist to make
> >> a selection of particular terms of use.
> >>
> >> kc
> >>
> >> [1] http://openlibrary.org/works/OL475973W -- a basic foundation
> >> for how librarianship views KO.
> >> [2]
> >> http://www.ifla.org/publications/functional-requirements-for-
> authority-data
> >>
> >> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> >>
> >>>>> It would be odd to dismiss SKOS because we determined it was
> >>> designed
> >>>> to
> >>>>> manage "concepts" rather than "controlled vocabularies".
> >>>>
> >>>> I certainly wouldn't want to dismiss SKOS! The point is that
> >>>> SKOS organizes sets of lexical strings via underlying concepts.
> >>>
> >>> I would argue that "organizing" concepts or labels is getting into
> >>> optional features of SKOS. Your other comments indicate you would
> agree.
> >>> The essential features for authority control, in my view, are the
> >>> ability to identify something real (a skos:Concept), associate
them
> in a
> >>> scheme (via skos:inScheme) and give them skos:pref/altLabels
> >>> (potentially "real" via skosxl:Label). Some forms of authority
> control
> >>> may want to use additional gravy from SKOS, but others could just
> as
> >>> well link out to other models via foaf:focus and organize from
> there.
> >>> Either or both ways, SKOS can act as a schematic naming network.
> >>>
> >>> Jeff
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
>

Received on Saturday, 4 December 2010 17:35:12 UTC