Re: SemWeb terminology page

Karen,
I have not completely followed the discussions since I am on the road.  Here just jump in to discuss a few.

On 12/4/10 10:29 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

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.

[MZ:] Let me use thesauri as example for controlled vocabularies below.
Like Jeff mentioned, a thesaurus can just be "one thing"  as you wished: A concept belongs to the skos:Concept class and is represented by an identifier.  This instance of the skos:Concept has its preferred and non-preferred labels, etc.  However, because these labels do not have its own class, they are attributes of a concept instance.   Theoretically an attribute does not have attributes.  In a real thesaurus management situation, in addition to the conventional relationships between concepts, we have to manage the relationships between different labels of a concept.  Different labels for the same concepts occur in most of the cases (e.g., one label is the abbreviation of another label, replaces another label, has a proposed and accepted date, has a particular script label, ect. (-- these are just something came out of my mine right now.))  These are the labels for the same concept instance, and have relationships and other attributes of their own.  Labels need to have them own identifiers.  Therefore labels belong to the skosxl:Label class.

I can show everyone the real examples of a thesaurus to be published in SKOS + SKOS XL in two or three weeks.  Right now because it is not formally released I do not want to publicize it.  But I can email you the piece if you like to see... which may explain why labels have to have their own identifier, literary form, and other SKOS XL properties to handle them.

The relationships of FRSAD entities and SKOS are:
thema => skos:Concept
nomen => skosxl:Label
                 (skosxl:prefLabel; skosxl:altLabel; skosxl:hiddenLabel;
                 skosxl:literalForm; skosxl:labelRelation)

On 12/4/10 10:29 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
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?

MZ:  My understanding is that It is not whether they are two things.  It is how the concepts and the labels of the concepts are presented, published, and used in indexing.  I see more and more thesauri and other controlled vocabulary instances will be published in SKOS, some may choose to just use SKOS (concepts and concepts' attributes (including labels), or they may choose to use SKOS XL to handle labels, so the labels have their own URIs and other attributes.

In the interoperability approaches, some tasks focus on the concept mapping and some tasks are on labels.  In  ISO 25964 Information and documentation -- Thesauri and interoperability with other vocabularies,  this issue was discussed and it is emphasized that 'mapping' is between concepts, not between the labels representing the concepts. I could try to extract more text from the standard if needed, after I finish the trip.

Thanks for the discussion.  I will try to read all other discussions already posted on this thread.

Marcia Zeng


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