Thank you very much for sending the link on URI opacity. Both of your proposals are valid as one of you is from top-down approach or navigable map approach, and the other is bottom up approach. Naming scheme for media type is very important as music videos and other resources still remain as the uncharted frontiers for library folks.
In this message, I am proposing linking behavior needed for next-generation Lib catalog. It's called bidirectional hypertext link analysis and link base management.
One benefit is that both source and target can be tracked and analyzed by net-based applications, particularly in Cloud computing scenario.
It's more than what's in Google's page ranking which provides link analysis to the sources and identifying authoritativeness of the sources, a required feature which most Browser-based applications do not have.
For next generation Lib catalog, when data and associated metadata are exposed to the linked data cloud for libraries, we have the opportunity to monitor user data without storing identifiable personal info if we partitioned the data by segment of users, masking out or even removing any tracking info on individuals, e.g. IP addresses, etc.
We have better chance than before in delivering info more relevant to users. User interaction with lib resources are valuable data in understanding author and reader activities and other info contextually.
What are the implications to Lib resources in Web-scale management when URIs for bidirectional links with attributes for link analysis and link base management were defined as what's being proposed for Cool URIs?
It will definitely offer options for CRUD operations in both source and target for super users on the Web if being implemented properly in addition to authority identification and analysis, etc.
In short, instead of current proposal for hypertext link from source to target only, bidirectional link will also permit target-to-source hypertext linking. I believe it's time to reconsider such linking behavior, particularly for intentional discovery resources in Web-scale management.
I hope such proposal will provide some discussion point, and hopefully build consensus on the expected behavior of URIs, in addition to best practice in standardizing the implementation of URIs.
Sorry to push the envelop again!
Amanda Xu Sent from my iPhone
On Feb 6, 2012, at 10:34, "Huwig,Steve" <[log in to unmask]> wrote:
>> -----Original Message-----
>> From: Bibliographic Framework Transition Initiative Forum
>> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
>> Sent: Saturday, February 04, 2012 11:51 AM
>> To: [log in to unmask]
>> Subject: Re: [BIBFRAME] The German National Library's response
>> I think that the biggest gap right now is to formulate best practices
>> for the creation of URIs for the resources being described. That was
>> also a recommendation in the W3C LLD report. We have to assume that
>> bibliographic data will often be shared but could also be created
>> independently in different libraries. It would probably be a good idea
>> to have members of the library community using similar patterns for
>> resource identifiers even though they may mint those identifiers
>> independently. I also assume that most folks who will be creating
>> identifiers would like to have a set of best practices to lean on
>> rather than creating their own.
> While it's generally more helpful to have readable URIs than to have
> machine-generated ones, I think that effort expended to standardize URI
> construction won't be very effective. Naming and organizational
> conventions in one culture or system will likely not translate well to
> different cultures or systems.
> In my opinion, the most intellectual effort in this area should go into
> defining a bibliographic record media type, or a family of media types,
> or a framework for creating and using such media types. The idea is that
> if the automated systems have unambiguous ways to process these media
> types, then the users can expend as much or as little effort as they
> need on naming and organization.
> Naturally, the media type will use URIs and hyperlinking prolifically,
> but in the end computers don't really care what the URIs look like as
> long as they can be resolved. In fact, specifying URIs to be opaque in
> the data model will be very helpful, as then we can be sure that the
> transmission formats and system implementations won't need to rely on
> potentially ambiguous or contentious naming and organization schemes.
> More on URI opacity: http://www.w3.org/TR/webarch/#uri-opacity
> Steven Huwig