- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Wed, 21 Feb 2018 17:49:53 -0800
- To: Steven Rowat <steven_rowat@sunshine.net>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAAjunnbWFpnx2-+zCXAk1YisUctysKohOBVZXV2Q_eHN2qCAJQ@mail.gmail.com>
On Wed, Feb 21, 2018 at 9:08 AM, Steven Rowat <steven_rowat@sunshine.net> wrote: > On 2018-02-20 6:03 PM, =Drummond Reed wrote: > > Am I groping in the right direction here? >> >> >> Yes. Specifically the steps proceed as follows: >> >> 1. First, the DID is extracted from the DID service URL. >> 2. Secondly, the DID is resolved by a DID resolver into the DID document. >> 3. Thirdly, the correct service description object is selected from >> the array of service description objects in the DID document using >> the service name in the DID service URL. >> 4. Fourth, the service endpoint URL is extracted from the selected >> service description object. >> 5. Lastly, the path (and query and/or fragment) from the DID service >> URL is appended to the service endpoint URL to compose the target URL. >> >> Now the target URL can be used to get the SANC itself. >> > > Thank you, that's very useful; I'd been making the mistake of starting > from the DID Document in my sequence of trying to understand, but I see now > the service URL must come first, of course, just like a URL has to exist to > get to any HTML web page. > > At this point, is the above already agreed as how the DID naming will > operate? Or is it still in flux, as part of what's still being finalized on > the "DID Spec Completion Proposals" page, about how service naming is done, > etc.? > I can only say that at this point I believe we have general agreement on this mechanism. But to be safe, you should wait until the pull request for this feature is accepted. Our goal is to be really solid with the DID spec by the end of Rebooting the Web of Trust #6 in Santa Barbara (March 6-8). =Drummond > > Steven > > >> =Drummond >> >> >> >> Steven >> >> >> It's just an optimization, but it could help with efficiency. >> >> =Drummond >> >> On Mon, Feb 19, 2018 at 8:18 PM, Steven Rowat >> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net> >> <mailto:steven_rowat@sunshine.net >> >> <mailto:steven_rowat@sunshine.net>>> wrote: >> >> >> Greetings, >> >> (Please excuse the long post; I’ve shortened it several >> times but it’s >> a relatively complex proposal, so I don’t think I can >> present it well >> any shorter.) >> >> I’m mulling an idea that a DID method might allow a >> nested publishing >> system that links all designated stand-alone works by a >> single author. >> I’ve been calling such works SANCs (“stand-alone nested >> chunks”). >> “Nested” because they include smaller chunks inside a >> larger work, >> like stand-alone chapters from a book, special-use >> paragraphs inside a >> chapter, sample excerpts from a piece of music, or >> self-explanatory >> Figures from a scientist’s data set. >> >> I post here a first description of the idea, to ask if >> such a SANC >> publishing system seems technically feasible with DIDs. >> My hunch is >> that it’s an inevitable development when DIDs and linked >> data exist, >> and possibly people are already working on it elsewhere, >> though I >> don’t know of any at present. >> >> I give a slightly longer summary and two examples below, >> and some >> rationale at the end for why this might be a valuable use >> of the DID >> system. >> >> Any feedback appreciated. >> >> Summary: >> In the proposed Stand-Alone Nested Chunk (SANC) system, a >> “stand-alone” work is any discrete work by an author that >> the author >> believes will have its own audience or use. Taking text >> as an example, >> a SANC could be as small as a single sentence, paragraph, >> or graphic >> deemed noteworthy; or as large as a series of books. >> Every SANC gets a >> DID Document. Every DID Document contains meta-data >> (and/or links) to >> facilitate end-user access to the parent section of a >> SANC; laterally >> to other SANCs at the same level; and to other larger >> works or groups >> of works, all of which are also SANCs. Depending on the >> implementation, portions of this linked access might use >> a permissions >> language like ODRL, including for payments, sample >> excerpts, and usage >> rights. >> >> Example 1, Scientist: >> >> Scientist M issues a report, “String Theory Today”, with >> Abstract, >> Purpose, Method, Graphs, Data (containing Figures), >> Discussion and >> Conclusions. Scientist M has published many different >> reports over >> his/her career. Five earlier reports were directly >> related to String >> Theory. From the current report, Scientist M believes >> that the >> Abstract, Data, Conclusions, and two of the Figures from >> Data, and the >> last paragraph of the Conclusions, would each be useful >> in various >> collaborations, including as stand-alone statements in >> news and >> science-preview sites. >> >> Scientist M therefore, to get up to speed in the SANC / >> DID system, >> issues (or authorizes the issuing of) DID Documents for >> each SANC that >> is designated as a meaningful unit: >> —Scientist M him/herself; (1 DID Doc) >> —M’s full list of past reports; (a DID Doc for each report) >> —M’s group of String Theory reports; (1 DID Doc for the >> group) >> —M’s New report, “String Theory Today”; (1 DID Doc) >> —Abstract, Data, and Conclusions of the new report (3 DID >> Docs); >> —2 Figures from the Data; (2 DID Docs) >> —A paragraph from the Conclusions (1 DID Doc). >> Every DID Document contains a way to access all other >> works (SANCs) by >> the same author, including getting meta-data about the >> author and >> his/her works. >> >> Example 2, Musician/lyricist/poet: >> >> For each of the following: >> —“A thing of beauty is a joy forever”. >> —“No eternal reward will forgive us now for wasting the >> dawn”. >> —“This is the way the world ends / not with a bang but a >> whimper”. >> Who wrote it? What larger work is it part of? What else >> did they >> write? Can we read their other work now? Do we have to >> ask permission >> or pay someone in order to get access to their work? >> >> The proposed SANC / DID system could answer all these >> questions on the >> basis of the user encountering a single work by the >> author, of any >> size. >> >> Discussion: >> The questions posed in Example 2 could equally apply to >> Example 1; and >> to any other examples that can be envisioned for other >> types of works. >> And an argument might be made that all these questions >> can be answered >> by searching the Internet, but I see at least two strong >> reasons why a >> SANC / DID system would be an improvement: >> >> 1. Author control: >> Currently, Google, Wikipedia, and various advertisers and >> plagiarizing >> sites constitute an industry feeding on the data that is >> created >> and/or enabled by authors. In the SANC / DID system, an >> author has the >> right to arrange and benefit from both the meta-data >> linking the SANCs >> and from the SANCs themselves. >> >> 2. More Effective Distribution: >> Young authors, or authors of any age who are just >> starting out, will >> often not be easy for an end-user to track down, even if >> their works >> have real value to the society. If an end-user can answer >> all the >> above questions easily, via a single work (SANC) they >> encounter by the >> author, it will increase the dissemination speed of that >> author’s >> works through the society, with much less middleman overhead. >> >> Final note: I think there are a large number of people >> who might make >> use of a SANC / DID Document system to publish their >> work: novelists, >> journalists, filmmakers, bloggers, and so forth. And it >> isn’t limited >> to single persons: groups—any legal entity—could make use >> of it; >> including governments who have complex layered material >> they must >> supply; corporations with internal documents or >> user-manuals to >> manage; and educational institutions with intricately >> inter-related >> course materials. >> >> >> All feedback appreciated, especially detailed warnings. ☺ >> >> Steven Rowat >> >> >> >>
Received on Thursday, 22 February 2018 01:50:20 UTC