RE: [VM] Scoping Draft with questions to TF members

Just two new comments, they are in line in the message, but also pulled
up front for convenience.

Mike


    Were you thinking one might find a different example for each
    principle, or find _one_ example to provide a common point of
    reference to drive _all_ of the principles?
[MFU] One example to illustrate all the principles is better than lots
of different ones. Though sometimes it is hard to find a single example
to illustate all points.
[MFU] 

===
    I see the point, though this seems like one of those
    issues just beyond the scope of the core principles --
    a good candidate for brief discussion in Section 4, 
    with pointers to further reading.

[MFU] Hmmm: I'm thinking that this is a MAJOR POINT that should be
driven home in a compelling way.  One way to proceed is in effect to use
OWL as a way to represent a thesaurus lang: if you do it this way, these
are the consequences. If on the other hand, you use OWL in a different
way, then here are the consequences of THAT decision.  Perhaps I'm
missing the main purpose of this document? It seems to me that if you
want to include thesauri, taxonomies, controlled vocabularies etc in a
Semantic Web-friendly way, then this is about the first question to ask!
[MFU]

-----Original Message-----
From: Thomas Baker [mailto:thomas.baker@bi.fhg.de] 
Sent: Friday, September 03, 2004 2:31 AM
To: Uschold, Michael F
Cc: Thomas Baker; SW Best Practices
Subject: Re: [VM] Scoping Draft with questions to TF members

On Thu, Sep 02, 2004 at 08:48:20AM -0700, Uschold, Michael F wrote:
> See inline comments labelled by [MFU]

Thank you, Michael.  Taking the issues out of order...

1. Defining our terms

    >     Section 1. Terminology
    > 
    >        I assume that we would need to agree -- at least for
    >        the purposes of the VM note -- on the meaning of some
    >        basic terms.  Section 1, then, would define a list of a
    >        dozen or so basic terms such as "term" and "vocabulary".
    > [MFU] Good idea, but it may be more challenging than you think.
    ...
    > [MFU] I think it makes sense to see if you can get agreement on at
least
    > a handful of key terms, if only for the purpose of writing the
note.
    > What is most likely to occur is that a given term will in fact
refer to
    > a handful of distinct (though related) concepts/notions.
Focussing on
    > defining TERMS can lead to endless round-in-circles discussions. I
find
    > it more productive to FIRST identify the important
NOTIONS/CONCEPTS that
    > you need to talk about, choose the ones that you want terms for,
and
    > then try and find term that everyone agrees to.  ...
    ...
    > [MFU] You also will need to note somewhere that the terms have
other
    > meanings that are commonly used, but that you are using them in
ONE
    > PARTICULAR WAY.

    I have actually gone through this very exercise in a
    working group before, and it was indeed more difficult
    than we had originally thought.  So I emphatically agree
    that we should try first to agree on what we want to say,
    then try to agree on the handful of terms needed to say it.
    Those terms could then be defined "for the purposes of
    this paper" and important variants could perhaps be cited
    and described with a sentence each in footnotes.

2. About Section 2 - the general section on "vocabularies in 
   the Semantic Web"

    > [MFU] Many of these are not vocabulary-specific, and pertain to
other
    > areas.  Beware of scope getting too big - and/or keep the
discussion of
    > the general issue specific to how it impacts on vocabulary
management.
    > [MFU] See following link for some good input on this.
    >
http://www.metamodel.com/article.php?story=20030115211223271&mode=print 

    Link noted - thank you.  I very much agree that this
    section needs to be tightly scoped.  I think the section
    should say something like the following -- and in no more
    than two or three pages:

       The Semantic Web is an open, distributed, loosely-coupled
       environment with lots of languages (metadata element
       sets, controlled vocabularies, taxonomies, thesauri,
       ontologies, etc).  Organizations or even individuals can
       define and publish vocabulary terms in an open, bottom-up,
       and distributed manner.

       This paper articulates some basic principles for
       doing so in a Semantic-Web-friendly way.  By this
       we mean vocabularies that can support processes of
       referencing, repurposing, recombining, or merging
       data from a diversity of sources; that are evolvable;
       that are extensible and mixable with other Semantic
       Web vocabularies; and that are declared in a way that
       is processable by networked machines in an emerging
       "semantic infrastructure".

    Some of the TF members have perhaps written such things
    before.  Would anyone like to own this section?

3. About Section 3 - the "core principles"

    > [MFU] Again, some of these things are more general issues that
pertain
    > outside vocabulary management. It would be helpful to identify
when this
    > is the case, and feed that information back to the WG which could
be
    > input to a more general note about things that apply across TFs.

    This Scoping Draft was intended to draw fire and flush out
    such issues.  Here is another stab at articulating what I think
    the message of Section 3 should be:

        Identify your terms with URIs.
        Articulate policies about the identified terms.
        Publish those policies.
        Document the terms.
        Declare the terms in schemas.
        Identify versions of terms with URIs.
        Identify sets of terms (and their versions) with URIs.

    All of the above seem (to me) to be within the scope of
    "vocabulary management".  Perhaps you were referring to
    the last two points in the draft:

    >    -- Only a Namespace Owner should change the meaning of a Term 
    >       in a namespace (though non-owners may constrain meanings in
    >       semantically compatible ways for use in specific contexts).
    > 
    >    -- When making assertions about terms belonging to another 
    >       Namespace Owner, consider seeking their endorsement of 
    >       those assertions ("assertion etiquette" or "good neighbor" 
    >       policies).

    Is it perhaps that you see these points as beyond the
    scope of "managing your own vocabulary"...?

    >                                     ...   Do you agree that
    >    not all of the principles need to be "Must" principles --
    >    that some could be "May" or "Also Consider" principles?
    >
    > [MFU] This seems like a good idea, modulo the long discussions we
had
    > about not dictating what people should do, but rather saying if
you do
    > this or that, these are the consequences of those decisions.

    Agreed.

4. Use of examples in Section 3

    >                                 ....  Personally, I believe
    >        that if we could articulate half a dozen or so simple
    >        principles and elaborate on each principle in two or
    >        three paragraphs, with pointers to actual practice,
    >        these principles could form the core contribution of
    >        the VM note.
    >
    > [MFU] If possible, find a good example to drive this.

    I like the idea of using examples to provide a focus.

    Were you thinking one might find a different example for each
    principle, or find _one_ example to provide a common point of
    reference to drive _all_ of the principles?
[MFU] One example to illustrate all the principles is better than lots
of different ones. Though sometimes it is hard to find a single example
to illustate all points.
[MFU] 

    For example, Dublin Core -- the vocabulary I know best --
    identifies terms with URIs, has a URI policy, identifies
    versions of terms, associates the URIs with representations
    (schemas that include definitions), etc, etc.  It could
    serve as such a common example.  Surely, though, we would
    want to point off to many instances of good practice in
    a variety of vocabularies...?

    In other words, is it more helpful to focus on one (or a
    handful) of "driving" examples or to cite lots of examples
    from different types of vocabularies?

5. About Section 4 - the "peripheral issues"

    >        On many issues we will not be able to agree, whether
    >        because the issues are controversial (e.g., the idea of
    >        "ownership" of a namespace which surfaced on this list
    >        in response to an earlier draft) or because they are
    >        the object of ongoing discussion and experimentation.
    >        We should try to distill these issues down to a
    >        "manageable" number -- a dozen or so -- and discuss
    >        each issue in one or two paragraphs which describe
    >        the issue and characterize the main viewpoints, areas
    >        of development, or controversies, with pointers to
    >        the literature.  In my opinion, a "manageable" number
    >        is important not just to aid the reader, but also to
    >        allow us to divide ownership of the issues among Task
    >        Force members.
    > [MFU] It is important to keep scope within reason. In the event
that too
    > many thing emerge to be addressed, some priorities will have to be
set,
    > and criteria for them.  In this event, it would be useful to at
least
    > MENTION that many other issues arose, name and discuss the issue
in a
    > sentence or two, and comment on when/whether it might need to be
    > addressed in the future, how important is it? Why, why not?

    I completely agree.  I picture Section 4 as the place we
    flag such issues.  By "distill to a manageable number",
    I was picturing that we would try to cluster many of the
    sentence-or-two issues under just a dozen headings or less.

    > [MFU] The phrase "the identification of terms and term sets
    >         with URIs, related policies and etiquette, and
expectations
    >         regarding documentation" might be extended to include
    > representing things using OWL.  Perhaps that's implicit and
obvious and
    > not needed to be said?  Here is one way to use OWL to represent a
    > thesaurus: create properties for the standard thesaurus relations:
    > narrower-than, related-to etc. This effectly encodes the thesaurus
    > language in OWL rather than using OWL directly. THis is a very
important
    > issue that should be addressed. I have seen this kind of thing
done. It
    > ahs the advantage of simplicity, but it also seems like a hacky
way to
    > do something, and it tends to make minimal use of any of the
built-in
    > features of OWL.

    I see the point, though this seems like one of those
    issues just beyond the scope of the core principles --
    a good candidate for brief discussion in Section 4, 
    with pointers to further reading.

[MFU] Hmmm: I'm thinking that this is a MAJOR POINT that should be
driven home in a compelling way.  One way to proceed is in effect to use
OWL as a way to represent a thesaurus lang: if you do it this way, these
are the consequences. If on the other hand, you use OWL in a different
way, then here are the consequences of THAT decision.  Perhaps I'm
missing the main purpose of this document? It seems to me that if you
want to include thesauri, taxonomies, controlled vocabularies etc in a
Semantic Web-friendly way, then this is about the first question to ask!
[MFU]


Tom

-- 
Dr. Thomas Baker                        Thomas.Baker@izb.fraunhofer.de
Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
Personal email: thbaker79@alumni.amherst.edu

Received on Friday, 3 September 2004 19:14:27 UTC