RE: SemWeb terminology page

The practical use cases I can think of for skosxl:Label is an object
property link to audio pronunciation or possibly a datatype property for
phonetic spelling. I suspect that FRSAD Nomen has thoughts of other
possibilities. The Nomen is where they attached their "schema" property,
which is a possibility for skos:inScheme. Normally, though, this would
be assigned to the skos:Concept.
 
Jeff

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Saturday, December 04, 2010 4:07 PM
> To: Young,Jeff (OR)
> Cc: public-lld
> Subject: RE: SemWeb terminology page
> 
> 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 22:44:41 UTC