Re: [dsii] Potential IETF Work Items

Guangqing Deng <dgq2011@gmail.com> Mon, 27 August 2012 06:43 UTC

Return-Path: <dgq2011@gmail.com>
X-Original-To: dsii@ietfa.amsl.com
Delivered-To: dsii@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1321F8533 for <dsii@ietfa.amsl.com>; Sun, 26 Aug 2012 23:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwvLC-LftcU2 for <dsii@ietfa.amsl.com>; Sun, 26 Aug 2012 23:43:53 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 273B221F84B2 for <dsii@ietf.org>; Sun, 26 Aug 2012 23:43:53 -0700 (PDT)
Received: by iabz21 with SMTP id z21so8460596iab.31 for <dsii@ietf.org>; Sun, 26 Aug 2012 23:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2VszImgZKZQSHhUXgsVwL/3NaQ7gyApFFtiWkNm0jcg=; b=r01bkQwF4mWlAsMmibxadALXDVXWNajIFT4bjjtR3A3asqeNaqRvoHcaiVhLfa3E/m IOnbYvfVCK4M2FGkhEbDiaEiZ2l0aQHAmDTcsKey7SoUtYNZzU++zzN/y3Q2oQVNBam8 +i9/h0io4ZG83490PO6s3UsJdlMhjMW17WdNTh3ApbJYfH7wkFuo6LHrLWZwIU7QjYvq H6px3Qlt16b4ROszrb4eaYVkt5N1s5vWp0bI6lfdDZY01uou0IYstl1LKKb9OmMKCoZg F38Z8YRL8sCsKnhFflRKrQdSZFbKQ7vyFSvE8VP5VAXjhl7QqJX0fCED0ZkP6GRu/bpR m8UQ==
MIME-Version: 1.0
Received: by 10.50.87.164 with SMTP id az4mr9038409igb.43.1346049832628; Sun, 26 Aug 2012 23:43:52 -0700 (PDT)
Received: by 10.64.52.68 with HTTP; Sun, 26 Aug 2012 23:43:52 -0700 (PDT)
In-Reply-To: <E42F4F32-3E9E-4F06-85CC-1C7FEBE73E01@cs.indiana.edu>
References: <E1AB8352-7B89-4D5A-9B36-4872DF105392@vigilsec.com> <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <CAPv4CP-SOmFAKqdm+3Xa9oBwNxd_f4dGyAQu7aesaEbc_quLgQ@mail.gmail.com> <CA+9kkMBpwaxHUMXegcQ6j1pPqgmb4k=130BaoDVp6HQ_Kh1Syw@mail.gmail.com> <502BC103.4040107@nomountain.net> <CA+9kkMCDF7LeeJw+G9-DHhxTsz3wC_8SWbPRjyzSDgaTzyA77g@mail.gmail.com> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> <E42F4F32-3E9E-4F06-85CC-1C7FEBE73E01@cs.indiana.edu>
Date: Mon, 27 Aug 2012 14:43:52 +0800
Message-ID: <CAL4OH3QEbMJtEEJRnD=8X=L3bm+C5Xr0CQt78nGYTvy-eoTw_g@mail.gmail.com>
From: Guangqing Deng <dgq2011@gmail.com>
To: Beth Plale <plale@cs.indiana.edu>
Content-Type: multipart/alternative; boundary=e89a8f3ba6771fafcb04c839a676
Cc: dsii@ietf.org
Subject: Re: [dsii] Potential IETF Work Items
X-BeenThere: dsii@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dsii.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsii>, <mailto:dsii-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsii>
List-Post: <mailto:dsii@ietf.org>
List-Help: <mailto:dsii-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsii>, <mailto:dsii-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 06:43:54 -0000

2012/8/27 Beth Plale <plale@cs.indiana.edu>;

> This is an important conversation.  The issues with data identification
> are surfacing in science because science data is at multiple levels of
> granularity (e.g., national, state, metro area, street) and giving proper
> credit to data creators is of burgeoning important in the sciences.
>  Commercial video can have issues of granularity but once copyright issues
> are resolved, ownership is clear.   The issue of ownership/attribution is
> driving the urgency to come up with solutions to the data set identifier
> problem.
>
> I see interoperability across ID schemes as something that IETF can help
> us think about and propose a solution to.  We're not going to accomplish
> much by trying to mandate a single ID scheme, not with several already in
> existence and with good adoption.  Ted and Andrew identified this problem
> as well.   I wished we'd had more time to discuss interoperability at the
> BOF.
>
> I like the connections Andrew made to work going on in other IETF groups.
>  That shows hope that there's existing expertise from which we can draw.
>
> I see this topic as cloud-agnostic.  Clouds are heavily researched and
> used in academia; identifiers would describe data sets wherever they
> "live", and clouds are likely to be or already heavily used for replication
> (caching).
>


BTW, clouds are widely applied by the industry. The aim of replication in
clouds is to keep the data "live" (namely to avoid a single point of
failure), so replication just is a means but not the purpose.


>
> The library folks bring a lot to the table, but are a subset of those
> interested in this topic.  Leif's remark  libraries are increasingly
> operated by content providers (who are at IETF) is a strong tie.
>
> Finally, Andrew's suggested 3 options for engagement (copied below) are
> very good.
>
>
> On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote:
>
>
> Three options for engagement seem worthwhile considering:
>
> 1. More dsii-interested folks currently outside IETF could start
> participating
> in WGs w cross-cutting interests, once they are identified.
>
> 2. More IETF'ers could be engaged to participate in current dsii
> initiatives outside the IETF and be offered a platform from which
> an IETF perspective can be heard. ("Big Data" seems to be getting
> big these days for better or worse).
>
> 3. A dsii working-group might someday be formed within IETF.
>
> I think that the first 2 options are pre-requisites for the 3rd so
> that we can gain familiarity with each others use-cases and cultures
> and thus lower the risk of a "bad start". As I have gotten older I
> have learned how important "good starts" are to initiatives.
>
>
> best
>
> beth
>
> : Beth Plale
> : Director, Data to Insight Center
> : Professor of Computer Science
> : Indiana University Bloomington
>
>
> : Beth Plale
> : Director, Data to Insight Center
> : Professor of Computer Science
> : Indiana University Bloomington
>
>
>
>
>
>
>
>
>
>
>
>
> On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote:
>
> On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote:
>
> I'm still trying to figure out what's being proposed here and I
>
> realized that my mental model might be considerably different from
>
> that being used by the work's proponents.  Where I'm coming from,
>
> someone who needs a chunk of data and isn't sure where it is (or,
>
> in some cases, whether or not it exists) does a search, and the
>
> search returns a set of stuff, where "stuff" includes descriptive
>
> information (metadata) and an identifier that's actually a
>
> locator.  The locator is used to access the data.
>
>
> Is that consistent with what proponents have in mind?
>
>
> Hi Melinda.
>
> The above is the primary use case. I think the "stuff" is all metadata
> (attribute/value pairs about the dataset) that includes the "locator" you
> mention.
>
> I'd like to comment on some of the things I saw of value at the Vancouver
> meeting. I don't claim to be an identifier or metadata expert so perhaps
> some of these ideas were derived outside of IETF. But they were new to me.
>
> One idea would be to consider working together to agree on the "core
> metadata" that would be returned about scientific datasets for data object
> access and delivery, etc.
>
> One of the more interesting IETF WG docs I found was the CDN Interconnet
> Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on ACLs,
> ACLRules, Delivery seemed directly applicable to delivery of science
> datasets, some of which are proprietary and some of which are not. There
> are all sorts of issues related to delivery of proprietary scientific data
> and very large datasets (or their subsets) that seem applicable.
>
> I noticed in another I-D (can't find it right now) the practice of
> allowing attribute values of type "URI" being either an explicit, fully
> qualified URI *or* a regular-expression substitution that can be applied to
> a previously defined URI attribute.
>
> So, for example, if the URI for my identity as a WHOI employee was "
> http://www.whoi.edu/1912/241.11" the URI for a picture of me might be
> specified in the metadata associated with this URI as "s/$/.jpg/",
> indicating that adding .jpg to the end of the locator URI derives a picture
> of the person.
>
> Another example might be a way to define the way to express a substitution
> string for receiving metadata about a timeslice of a video that is pointed
> to by a locator for a scientific data object of type "Video". If the
> orginal locator was http://www.whoi.edu/1912/2342.234 there might be
> metadata that declares how to modify this URI to one that specifies a start
> time and end time.
>
> I'm interested in finding "lessons-learned" by the IETF that it would be
> worth considering in the realm of dataset identifier interoperability.
> Information in the I-Ds represent hours and hours of discussion/argument
> and trial in past meetings about what works and what does not work.
>
> It would be a shame if we could not find some way to take advantage of
> this work done in the past to help with datset identifiers and certain
> types of the metadata that would sit behind them.
>
> --Andy
>
> _______________________________________________
> dsii mailing list
> dsii@ietf.org
> https://www.ietf.org/mailman/listinfo/dsii
>
>
>
> _______________________________________________
> dsii mailing list
> dsii@ietf.org
> https://www.ietf.org/mailman/listinfo/dsii
>
>


-- 
Guangqing Deng