Re: SemWeb terminology page

On Sat, Dec 04, 2010 at 01:06:44PM -0800, Karen Coyle wrote:
> 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?

AGROVOC, for example, models all labels as resources using
skosxl.

One key reason -- and the reason which motivated the
requirement for skosxl:Label in the design of SKOS
in the first place [1] -- is to be able to express
relationships between labels such as "IBM is an acronym
for International Business Machines" (hasAcronym) or
"The term X is a synonym for the term Y" (hasSynonym).

In AGROVOC, labels-as-resources also provide attachment points
for things such as status, date created, and AGROVOC code.

Tom

[1] http://www.w3.org/TR/skos-ucr/

> 
> 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
> 

-- 
Thomas Baker <tbaker@tbaker.de>

Received on Saturday, 4 December 2010 22:40:21 UTC