W3C home > Mailing lists > Public > public-lld@w3.org > December 2010

RE: SemWeb terminology page

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 04 Dec 2010 13:06:44 -0800
Message-ID: <20101204130644.39824jbew5wg4q5g@kcoyle.net>
To: "Young,Jeff (OR)" <jyoung@oclc.org>
Cc: public-lld <public-lld@w3.org>
Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:

> Karen,
>
> Note that skosxl:Label is available for the "two thing" model you refer
> to. SKOS-aware processing should presumably treat skos:prefLabel and
> skosxl:prefLabel interchangeably:

Thanks, Jeff,

Other than generating more lines of code and making systems work  
harder :-), can you see any advantage to the two thing model with  
skosxl? Are there functions you have that you wouldn't have using  
Concept and prefLabel?

kc

>
> ex:hunger a skos:Concept ;
> 	skos:inScheme ex:myScheme ;
> 	skos:prefLabel "Hunger" ;
> 	skosxl:prefLabel ex:hungerLabel ;
>
> ex:hungerLabel a skosxl:Label ;
> 	skos:inScheme ex:myScheme ;
> 	skosxl:literalForm "Hunger" ;
>
> ex:myScheme a skos:ConceptScheme .
>
> "Controlled vocabulary" systems should be able to choose either or both
> approaches.
>
> Jeff
>
>> -----Original Message-----
>> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
>> Behalf Of Karen Coyle
>> Sent: Saturday, December 04, 2010 10:29 AM
>> To: Antoine Isaac
>> Cc: public-lld
>> Subject: Re: SemWeb terminology page
>>
>> Antoine, I agree with your thinking, but I'm not sure how to make it
>> acceptable to libraries, especially if they continue to see the name
>> as the "thing," which I believe is the prevalent viewpoint. cf. FRSAD
>> which has two entities: thema (the concept) and nomen (the name given
>> to the concept). I would tend to model subject authorities as a
>> concept (with a URI), a variety of labels (prefLabel, altLabel, etc.),
>> and a good definition. In my version, there is only one "thing": the
>> concept. In the library version there are two things: the concept and
>> the name. Is this a difference that matters? Or is it just two ways of
>> saying the same thing?
>>
>> As for MADS, all of the MADS elements have been defined as subordinate
>> to SKOS. In fact, I think that madsrdf:authoritativeLabel might be
>> skos:prefLabel with provenance. FRAD defines it that way, in a sense,
>> by adding guidance rules and the producing agency to both the
>> identifier and the name. This fits in with the madsrdf definition of
>> authority:
>>
>> "Authoritative (also Authority, Authoritative form): the endorsed form
>> of something"
>>
>> That definitely implies that there is an agent doing the endorsing.
>>
>> kc
>>
>> Quoting Antoine Isaac <aisaac@few.vu.nl>:
>>
>> > Hi Karen,
>> >
>> > Trying to reformulate your objections would lead me to something
>> like:
>> > - a linked data reference dataset focuses on reference URIs
>> > - a library reference dataset focuses on the terms
>> > So a "Library Linked Data reference dataset" should aim at giving
>> > URIs and not forget the terminological aspect?
>> >
>> > I don't think this in real contradiction with the idea of what a LD
>> > reference dataset should be: of course on LD providing URIs is
>> > important but most often you want to put relevant data for these
>> > URIs. And there's no constraint on what should be relevant or not:
>> > it's not because it's LD that labels do not count. After all, one
>> > main interest of the dbPedia dataset for many LOD scenarios is also
>> > that it comes with all these traductions, and sometimes synonyms...
>> > There is clearly value for the entire LD world if the reference
>> > datasets can come with better terminological information contributed
>> > by the library domain.
>> >
>> > Now indeed this does not say precisely how to get from a traditional
>> > library authority file to a LD reference set. In fact there are many
>> > solutions: see how VIAF, from traditional authority data, generates
>> > all these representations (foaf:person, skos:Concept) which can be
>> > useful on the LD space. It is more a matter of being ready to accept
>> > that the authority data can be re-packaged according to many
>> > different models.
>> >
>> > By the way on the specific MADS/SKOS issue:
>> > madsrdf:authoritativeLabel is a sub-property of skos:prefLabel.
>> >
>> > Antoine
>> >
>> >
>> >> 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.)
>> >>
>> >> 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? 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." 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.
>> >>
>> >> 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 21:07:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:59 UTC