W3C home > Mailing lists > Public > public-xg-lld@w3.org > September 2011

"Namespace" = "vocabulary with URIs"?

From: Tom Baker <tbaker@tbaker.de>
Date: Mon, 5 Sep 2011 13:50:11 -0400
To: Emmanuelle Bermes <manue@figoblog.org>
Cc: Tom Baker <tbaker@tbaker.de>, Karen Coyle <kcoyle@kcoyle.net>, public-xg-lld@w3.org
Message-ID: <20110905175011.GC46032@julius>
On Mon, Sep 05, 2011 at 06:42:42PM +0200, Emmanuelle Bermes wrote:
> > Remaining problems, in my opinion:
> >
> >> >>    * Version policy for the resources identified by the URIs.
> >>
> >> lost version policy for the namespace itself
> >
> > The problem here, as I see it, is that the text refers both to "vocabulary" and
> > to "namespace" -- the latter sometimes as a synonym for "vocabulary" and
> > sometimes for a URI -- i.e., the base URI used to "derive" the URIs (as in:
> > "policies for the namespaces used to derive those URIs").
> >
> > If "namespace" is being used to refer to a URI, it does not make sense to talk
> > about "versioning" the namespace, because a URI is not versioned.  (A URI may
> > contain "versioning information", though that is not best practice for RDF
> > vocabularies, but even then, a URI with new versioning information is not a
> > "version" of an older URI - it is simply a new URI.)
> I guess 'namespace' is used in the sense of 'vocabulary with URIs' (as
> opposed to another kind of vocabulary / metadata elements set that
> wouldn't be designed for Linked Data).

...and this is the way alot of people use the word "namespace".  However, the
text currently refers to vocabularies as URIs as "RDF vocabularies", whereas
using "namespace" in the other meaning would break the following sentence:

    Organizations and individuals who create and maintain URIs for resources
    and standards will benefit if they develop policies for the namespaces used
    to derive those URIs.

As a test, try replacing "namespaces" with "vocabularies with URIs" in the above
sentence and you get:

    Organizations and individuals who create and maintain URIs for resources
    and standards will benefit if they develop policies for the "vocabularies
    with URIs" used to derive those URIs.

...which is circular and makes no sense.  BTW, I speak as someone who has
participated in very long and hair-splitting discussions about the ambiguities
of the word "namespace"...!

[1] http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page_take2#Develop_policies_for_managing_RDF_vocabularies_and_their_URIs

> >    BEFORE> Extensibility of use of the namespace by smaller organizations.
> Going back to [2], maybe what was intended was :
> "Some libraries or library organizations should play a leading role in
> curating the RDF representations of library metadata elements,
> including URIs, in a similar way to existing patterns of standards
> maintenance, where a specific organization acts on behalf of the
> community. Such roles should operate in a more cross-domain
> environment, to reflect the networking infrastructure of linked data.
> Agencies responsible for the creation of catalogue records and other
> metadata, such as national bibliographies, on behalf of national and
> international library communities should take a leading role in
> creating URIs for the resources described, as a priority over
> publishing entire records as linked data, to help local libraries
> avoid creating duplicate URIs for the same resource."
> But I can't really find this idea is the current recommendation.

It's not in the Recommendation about developing policies for managing RDF
vocabularies -- the one we are discussing -- but this topic is more or less
covered two points above, in [3], "Create URIs for the items in library
datasets".  Actually, that section ends with a sentence:

    Policies documenting institutional commitment ("namespace policies") should
    be published in order to allow users of URIs to make safe choices based on
    quality, stability, and persistence.

...that may no longer be needed there because it is covered in more detail two
points later.  I have marked it with a strike-through as a candidate for possible
deletion.  See: http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_recommendations_page_take2&diff=6191&oldid=6185

In the end, I still do not understand:

    BEFORE> Extensibility of use of the namespace by smaller organizations.

...and my preference would be to cut it.  However, I could live with the vaguer:

    AFTER>  Extensibility of the vocabulary by other organizations.

[2] http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page#Identify_and_link
[3] http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page_take2#Create_URIs_for_the_items_in_library_datasets
[4] http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page_take2#Develop_policies_for_managing_RDF_vocabularies_and_their_URIs

> >> >> --  Removed reference to "Good practice guidelines and recipes for constructing
> >> >>    ontologies and structured vocabularies." -- out of place here.
> >>
> >> Not sure it's irrelevant : best practices would be needed when we're
> >> talking about providing URIs for a vocabulary which wasn't primarily
> >> designed for the Semantic Web (e.g. RDA)
> >
> > I do not think the point it irrelevant; it just seems out of place in a
> > paragraph that focuses on managing RDF vocabularies and URIs.  Maybe it could
> > be turned into a full sentence and added to the end of the point on "Develop
> > library data standards that are compatible with Linked Data" [2].
> Point taken, it would make sense.

How about, at the end of the point on "Develop library data standrds":

     There is a need for best-practice documentation and recipes to guide
     participants in library-world standardization efforts in the construction of ontologies
     and structured vocabularies.

In context: http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_recommendations_page_take2&diff=6193&oldid=6191

Received on Monday, 5 September 2011 17:50:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:58 UTC