Re: [dsii] Potential IETF Work Items

Guangqing Deng <dgq2011@gmail.com> Mon, 27 August 2012 06:30 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 3813921F854B for <dsii@ietfa.amsl.com>; Sun, 26 Aug 2012 23:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.941
X-Spam-Level:
X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=1.057, 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 W3I9Hgjc4nJq for <dsii@ietfa.amsl.com>; Sun, 26 Aug 2012 23:30:10 -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 9235721F8472 for <dsii@ietf.org>; Sun, 26 Aug 2012 23:30:10 -0700 (PDT)
Received: by iabz21 with SMTP id z21so8437914iab.31 for <dsii@ietf.org>; Sun, 26 Aug 2012 23:30:10 -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=eg3FvzBnCM8uFfQiVDK5A9SWfQPMaKogy0m0lF5+Cus=; b=Hoq7GXFSGpAf5CbfT81A/zpDTUzXsZWuS9163ZpAjyaN553sqBdQRU8zVmr/rwuS04 UoFwBd0v3NFTzFkW8eM2OVf2o9P14lRqO4vRbYSo63DRGaGn81+WoTOTdtQa5JzSzAaK gY4C2QEEKc6PzH4vHuCT5j+wCwfCkWhukf89tir+3AW1AfHA/qr7TRssbhwU6Fhs2UXF 7kgJsF8Kitcqk51Pq4kKm9iVDuV2cKX3u5/KUaCZNW17FZTnnWTr4ZHwi4VqOohx0PBP AYWOMyPtZgE2bj6blgC9UHynd5DMh8zcdAj/JLa867t6UhNYsclKHdSFnKUzL/WadZ1j DDHw==
MIME-Version: 1.0
Received: by 10.50.209.99 with SMTP id ml3mr9211031igc.31.1346049010011; Sun, 26 Aug 2012 23:30:10 -0700 (PDT)
Received: by 10.64.52.68 with HTTP; Sun, 26 Aug 2012 23:30:09 -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:30:09 +0800
Message-ID: <CAL4OH3Tk=PGkkgDSHytboTaepdWcqxS=Vx1MUs3_dYNhLSevjQ@mail.gmail.com>
From: Guangqing Deng <dgq2011@gmail.com>
To: Beth Plale <plale@cs.indiana.edu>
Content-Type: multipart/alternative; boundary=14dae9340a93178d5b04c83975ec
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:30:12 -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, Cloud also is widely applied in the industry.


> 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