PIMCity · YouTube · 4:35
This 120-second clip introduces the PIMCity Data Provenance tool and then demonstrates its REST API through Swagger UI. The first minute is a static explanatory slide stating that the tool watermarks personal data, such as browsing datasets, to verify ownership. The speaker emphasizes that the tool verifies ownership rather than handling full data trading. The remaining part shows a practical workflow: upload a local file via POST '/ipfs/dataset', receive a hash identifier, and retrieve the stored content via GET '/ipfs/dataset/{queryId}'. The clip is mainly conceptual and procedural rather than formula-based. This 120-second clip demonstrates an applied API workflow for dataset watermarking and verification. It begins with an IPFS hash used to retrieve a file, then sends that same hash to a watermarking DP module endpoint, which returns a `newHash`. The final part opens the verification endpoint `/dp/wm/{queryId}`, enters the `newHash`, supplies a private-key array, and changes the integer threshold `alpha` from the default 10 to 7 to match a file with seven URLs. The narration emphasizes reusing the same private key for verification and explains that a threshold above seven would not work in this example. The actual verification response is not shown before the clip ends. This 35-second clip shows a Swagger UI demonstration of a data provenance watermark-verification workflow. The visible request is `GET /dp/wm/{queryId}` with `queryId = QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;`, `key = [-26, -52, 8, 60, 76, 61, -81, -13, -9, -106, -96]`, and `alpha = 7`. The response area shows HTTP `200` and body `true`, which the speaker interprets as confirming that the dataset belongs to them. The ending highlights the `Download` button and the page title `Data Provenance API Docs`. No internal verification formula or proof is shown.
Use the learning inspector for key ideas and moments, or open the reading tabs for the complete notes.
Generated from the video's visuals and explanation; not verbatim speech.
The clip opens on a static presentation slide titled "PIMCity Demonstration" with the section heading "Data Provenance." While the slide remains unchanged, the narrator explains that the tool is meant to watermark personal data so ownership can be verified later. The key idea introduced here is not a formula but a workflow concept: attach provenance information to a dataset and keep evidence of who owns it.
The narration then gives the motivation. It says that companies such as Comscore place high value on web browsing data, so individuals may want to watermark their own datasets before sharing or monetizing them. At the same time, the speaker draws a boundary around the tool's function: it verifies ownership, and broader trading requires other PIMCity components. This distinction is important because the rest of the clip demonstrates storage and retrieval, not a full marketplace transaction.
The screen changes from the slide to a Swagger UI page labeled "Data Provenance API Docs." This is the online demonstrator mentioned in the narration. Several endpoint groups are visible, including watermarking-related operations, URL operations, IPFS operations, and dataset operations. The visual emphasis quickly narrows to the IPFS section because the next steps demonstrate how a file is stored and fetched.
The presenter expands the endpoint "POST /ipfs/dataset," described on screen as creating a new IPFS file. The request body expects a binary file under multipart/form-data. A local text file named "sample_urls_seven.txt" is selected, and the request is executed. The response body returns a JSON object that includes the file name and a "Hash" field. In the demonstrated logic, this hash is the identifier produced by the upload step.
Next, the presenter expands "GET /ipfs/dataset/{queryId}," whose description states that it gets a file from IPFS by hash id. The identifier obtained from the previous response is entered into the path parameter "queryId," and the request is executed. The response body then displays the retrieved text content, including multiple URL lines. This confirms the round trip: upload a file, receive an identifier, and use that identifier to recover the stored content.
In the final seconds, the speaker pivots back to the main theme, saying that the next goal is to watermark the file in order to verify and retain data ownership in the future. However, the clip ends before any watermarking operation is actually shown. Thus the segment completes the storage-and-retrieval demonstration but only introduces the upcoming watermarking step verbally.
The clip opens on a Swagger UI page showing a completed GET request to `/ipfs/dataset/{queryId}`. The visible description identifies this as retrieving a file from IPFS by hash id, and the response body lists several URLs. The speaker’s point is that the hash ID already used here will be reused in the next step.
The view scrolls to the IPFS API endpoints and selects the POST endpoint `/ipfs/dataset/{queryId}`, described as sending the queryId as an IPFS hash to watermarking in the DP module. This establishes the method: take the same hash and submit it for watermark processing rather than simple retrieval.
After execution, the response panel displays JSON including `"newHash":"QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm"`. The narration highlights that a new hash has been obtained, distinguishing it from the original IPFS hash entered in the path.
The interface then moves to the watermarking verification section and opens `/dp/wm/{queryId}`, labeled `Verify a WM Dataset by ipfs hash`. The speaker explains that this new hash, together with two additional parameters, will be used to verify that the dataset belongs to the user.
The parameter form shows `queryId` as a required path string, `key` as a required `array[string]` query parameter, and `alpha` as an integer query parameter with default value 10. The `queryId` field is filled with the `newHash`, and the `key` field receives a list of integer-like strings, illustrating the concrete input structure for verification.
The explanation turns to the threshold logic. The speaker states that if the file has seven URLs and the goal is to confirm that seven out of seven are correct and watermarked with the user’s private key, then `alpha` should be set to 7. The form is edited accordingly from 10 to 7.
The narration adds that `alpha` could also be set to a value less than or equal to seven, but more than seven would not work in this case. This makes the role of `alpha` explicit as a feasibility-bound threshold tied to the number of URLs being checked.
The Execute button is clicked to run the verification request. Within the provided clip, the setup is complete, but the final verification response is not shown before the video ends.
The clip opens on the lower half of a Swagger UI operation. The important visible result is the `Server response` block: code `200`, response body `true`. The generated request string above it shows a GET call to `https://easypims.pimcity-h2020.eu/provenance/dp/wm/QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;` with repeated `key` parameters and `alpha=7`.
As the narrator says, "Response body is true," the screen confirms that statement directly in the `Response body` panel. The next sentence, "Naturally that's correct, the dataset belongs to us," supplies the speaker's interpretation of that boolean output.
The page then scrolls upward to the request form. This reveals the operation header `GET /dp/wm/{queryId} Verify a WM Dataset by ipfs hash` and the parameter table. The visible inputs are `queryId` as a required path string, `key` as a required query array, and `alpha` as an optional integer query parameter.
While those fields remain on screen, the speaker summarizes the workflow: watermark a file, verify that the file belongs to the data owner, and use the API to perform that check. Mathematically, the clip is presenting an applied verification interface rather than deriving the watermarking rule itself.
The view scrolls back down to the response controls. The cursor hovers over `Download`, matching the spoken remark about downloading the file from the Swagger API tool itself. No file contents are opened; only the availability of the download control is shown.
Finally, the page scrolls up to the document header, where the broader context becomes explicit: `Swagger`, `Data Provenance API Docs`, `alpha0.3`, `OAS3`, and `Sample REST API documentation`. The clip ends as a short interface demonstration of provenance verification through a REST endpoint.
The video presents Data Provenance as a tool for watermarking personal data so that ownership can be verified later. The narration specifically frames this around datasets such as browsing data that the owner may want to share, spread among colleagues, or monetize.
The speaker explicitly says the tool verifies data ownership. If the owner wants to trade data further, other PIMCity components are required. This prevents conflating provenance verification with a complete marketplace workflow.
The online demonstrator is a Swagger UI page titled 'Data Provenance API Docs'. It exposes grouped endpoints, including IPFS-related operations used in the demonstration.
To store a dataset, the demo expands 'POST /ipfs/dataset', selects a binary file in the request body, executes the call, and receives a response containing a 'Hash' identifier for the uploaded file.
To read the stored content back, the demo uses 'GET /ipfs/dataset/{queryId}', places the previously returned identifier into the path parameter, executes the request, and displays the retrieved file contents in the response body.
The demonstrated file is 'sample_urls_seven.txt'. After upload, the response includes the file name and a hash. After retrieval with that identifier, the response body shows URL lines from the original file, confirming the upload-retrieve cycle.
The first step uses the GET endpoint `/ipfs/dataset/{queryId}` to retrieve a file from IPFS by its hash identifier. In the clip, the response body contains a list of URLs, and the speaker treats the hash ID from this step as the input to later operations.
The same IPFS hash is then sent to the POST endpoint `/ipfs/dataset/{queryId}`, described as sending the queryId as an IPFS hash to watermarking in the DP module. This step converts the retrieval identifier into a watermark-processing request.
Executing the watermarking request returns a JSON response containing `newHash`. The visible value is `QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm`, and the narration identifies this as the new hash that will be used for verification.
Verification uses `/dp/wm/{queryId}` with three inputs: the `newHash` as `queryId`, a required `key` array of strings, and an integer `alpha`. The clip shows these fields being filled before execution.
The speaker explicitly states that verification must use the same private key that was used when generating the watermark. The system does not record private keys for privacy reasons, so the user must supply the identical key again.
For a file with seven URLs, setting `alpha = 7` corresponds to requiring all seven URL checks to pass. Values less than or equal to seven are possible, but a threshold greater than seven cannot succeed in this example.
The video shows a Swagger operation labeled `GET /dp/wm/{queryId} Verify a WM Dataset by ipfs hash`. This identifies the demonstrated action as a dataset watermark verification request addressed by an IPFS-style identifier in the path.
The parameter table lists `queryId` as `string (path)` and required, `key` as `array[string] (query)` and required, and `alpha` as `integer (query)` and optional. The visible values are `QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;`, the array `-26, -52, 8, 60, 76, 61, -81, -13, -9, -106, -96`, and `7`.
The generated request string repeats the query name for each array element: `?key=-26&key=-52&key=8&key=60&key=76&key=61&key=-81&key=-13&key=-9&key=-106&key=-96&alpha=7`. This is the visible mechanism by which the form inputs become a concrete HTTP GET URL.
The response section shows HTTP status `200` and a response body of `true`. The speaker interprets this boolean as confirming that the dataset belongs to them.
Although the narration calls this a data provenance tool demonstration, the clip only exposes the API interface, request parameters, and boolean result. It does not show the watermarking formula, verification proof, or internal decision rule.
Near the end, the cursor hovers over the `Download` button while the speaker mentions downloading the file from the Swagger API tool itself. The final scroll reveals the page title `Data Provenance API Docs` with `alpha0.3` and `OAS3`.
Explore conditions, steps and evidence. Supplementary explanations are labeled separately from content shown in the video.
The introductory slide shows the label 'Data Provenance' and the abbreviation 'DP' in the explanatory paragraph.
DP
Data Provenance tool or module
software component name
The slide text mentions 'IPFS (InterPlanetary File System)'.
The Swagger page lists endpoints under 'ipfs The IPFS API Endpoints'.
IPFS
InterPlanetary File System, used as decentralized storage middleware
distributed file system
The GET endpoint is shown as '/ipfs/dataset/{queryId}' with parameter 'queryId * required string (path)'.
queryId
Path parameter identifying the stored item to retrieve from IPFS
string
The POST response body contains a 'Hash' field.
The GET request URL uses that same value after '/ipfs/dataset/'.
The exact hash string is not fully reliable from the visible frames; only its role as the returned identifier is clear.
Hash
Identifier returned after uploading a file to IPFS and used to retrieve it later
string
The GET endpoint is shown as `/ipfs/dataset/{queryId}` with the description `Get a file from IPFS by hash id`.
The speaker says to use "that same hash ID" and later refers to it as the first hash entered.
queryId
IPFS hash identifier used as a path parameter to retrieve a dataset/file from IPFS.
string path parameter; in this clip the visible value is an IPFS hash such as `Qmbaba7vv7UC61GyZsthPtcLMntDNQMTwZzyvYmqQuPW`
The POST response body shows `"newHash":"QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm"`.
The speaker says, "And note, we obtain a new hash."
newHash
Hash returned after sending the original IPFS hash to the watermarking DP module endpoint.
string; visible value `QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm`
The verification endpoint lists `key` as `array[string] (query)` and marks it required.
The speaker says, "We enter the private key," and later, "for verification here you must use the same key."
The exact semantic type of the private key beyond being supplied as an array of strings is not defined in the clip.
key
Private-key input for watermark verification, entered as an array of string values in the query parameter field.
array[string] query parameter; visible example values include `-26, -52, 8, 60, 76, 61, -81, -13, -9, -106, -96`
The verification endpoint lists `alpha` as `integer (query)` with `Default value : 10`; the field is edited to `7`.
The speaker explains that if the file has seven URLs and one wants to check that seven out of seven are correct, one sets the alpha threshold to seven.
alpha
Integer threshold parameter controlling how many URL checks must pass for verification to return true.
integer query parameter; default shown as 10, set to 7 in the example
The speaker says, "If our file has seven URLs and we want to check seven out of seven are correct... we set alpha threshold to seven."
The number seven is stated verbally; the underlying list of seven URLs is not enumerated in this clip.
seven URLs
Example dataset size used to justify setting the verification threshold to the maximum count.
count of URLs associated with the dataset/file
The Swagger UI parameter table shows `queryId` as a required `string (path)` and the input field contains `QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;`.
queryId
Path parameter identifying the dataset whose watermark is being verified.
string
The parameter table shows `key` as a required `array[string] (query)`, with visible entries `-26, -52, 8, 60, 76, 61, -81, -13, -9, -106, -96`.
key
Query parameter carrying the watermark key used for verification.
array of strings; displayed values are signed integers
The parameter table shows `alpha` as an optional `integer (query)` with value `7`.
alpha
Optional integer query parameter supplied to the verification endpoint.
integer
The speaker says the tool showcases how to watermark personal data to verify data ownership.
The slide title is 'Data Provenance' and the paragraph describes watermarking personal data such as browsing datasets while accounting for user data ownership.
The video defines the Data Provenance tool as a system for watermarking personal data so that ownership can be verified later. The spoken introduction emphasizes use cases where the owner wants to monetize, share, or spread data among colleagues.
Applies to personal data such as browsing datasets.
The tool verifies ownership rather than completing the whole trading process.
The speaker says companies such as Comscore value web browsing data highly, so users can watermark their datasets and try to monetize them further on.
The speaker adds that the tool will verify data ownership and that other PIMCity components are needed for farther trade.
The clip presents watermarking as a practical method for retaining proof of ownership over datasets that may have commercial value. It also states a limitation: this tool verifies ownership, while broader trading requires other components.
Intended for datasets whose owner wants future proof of possession or attribution.
Ownership verification is separated from full transaction handling.
The browser switches to a Swagger UI page titled 'Data Provenance API Docs'.
Visible endpoint groups include 'wm', 'urls', 'ipfs', and 'dataset'.
The demonstrator is a Swagger-based REST API documentation page for the Data Provenance service. The visible interface exposes grouped endpoints for watermarking, URL operations, IPFS operations, and dataset operations.
The page is an API documentation and testing interface.
Endpoint availability depends on the deployed server shown in the UI.
The expanded endpoint is 'POST /ipfs/dataset Create new IPFS file'.
The request body field is 'file string(binary)' with content type 'multipart/form-data'.
The speaker says, 'you can upload a dataset to IPFS.'
The demonstrated upload workflow uses the POST endpoint '/ipfs/dataset'. A binary file is submitted through a multipart/form-data request body, and the service returns a response containing a hash identifier for the stored file.
Requires selecting a local file in the request body.
The response includes a 'Hash' field used later for retrieval.
The expanded endpoint is 'GET /ipfs/dataset/{queryId} Get a file from IPFS by hash id'.
The parameter table shows 'queryId * required string (path)'.
The speaker says, 'If we want to see the content, we can use the get endpoint and retrieve the content.'
The exact hash string entered into the path is not fully reliable from the visible frames.
After upload, the file can be fetched again using the GET endpoint '/ipfs/dataset/{queryId}'. The path parameter carries the identifier returned by the upload step, and the response body displays the retrieved content.
Requires a valid 'queryId' corresponding to previously stored content.
The demonstrated response returns the file contents in the body.
Visible endpoint `/ipfs/dataset/{queryId}` with description `Get a file from IPFS by hash id`.
Speaker says to use the same hash ID to go to another endpoint.
The interface demonstrates using an IPFS hash as the `queryId` path parameter to fetch a dataset/file. The visible response includes a list of URLs, which the speaker treats as the file content or associated resource list.
The hash ID must be known.
The endpoint is a GET request.
The response is shown as JSON containing URLs.
Visible endpoint `/ipfs/dataset/{queryId}` described as `Send queryId as IPFS hash to watermarking in DP module`.
Speaker says to send the IPFS hash and watermark the contents thanks to the DP module feature.
A POST endpoint takes the same IPFS hash as `queryId` and submits it to a watermarking module. Executing the request returns a JSON object containing metadata and a `newHash`, indicating that the original hash has been transformed into a watermark-related identifier.
Use the previously obtained IPFS hash as `queryId`.
The request method is POST.
The response includes `newHash` and other metadata fields.
Visible endpoint `/dp/wm/{queryId}` with description `Verify a WM Dataset by ipfs hash`.
Speaker says the new hash will help verify, together with two other parameters, that the dataset belongs to ourselves.
The verification step uses the newly produced hash as the path `queryId` and additionally requires a `key` array and an integer `alpha`. The UI shows these as query parameters for a GET request to `/dp/wm/{queryId}`.
Use the `newHash` from the watermarking step as `queryId`.
Provide the same private key used during watermark generation.
Set `alpha` according to the desired verification threshold.
Speaker states that with seven URLs, checking seven out of seven means setting alpha threshold to seven.
The `alpha` field is changed from the default `10` to `7` before execution.
In this example, `alpha` is the minimum number of URL checks that must succeed for verification to return true. If the dataset contains seven URLs and the goal is to confirm all seven, the threshold is set to seven; setting it lower would relax the requirement, while setting it above seven cannot be satisfied.
The dataset/file is described as having seven URLs.
The intended verification is that all seven are correct and belong to the user.
`alpha` is an integer query parameter.
The page header reads `Wm Endpoints for Watermarking verification over datasets`, and the operation line reads `GET /dp/wm/{queryId} Verify a WM Dataset by ipfs hash`.
The video shows a Swagger UI operation for verifying a watermarked dataset through a GET request addressed by an IPFS hash in the path.
The interface is a Swagger UI page for `/provenancedocs`.
The operation is labeled `GET /dp/wm/{queryId}`.
The `Parameters` table lists `queryId` (`string (path)`, required), `key` (`array[string] (query)`, required), and `alpha` (`integer (query)`, optional).
The displayed request schema distinguishes one required path string, one required query array, and one optional integer query parameter.
`queryId` is required and belongs to the path.
`key` is required and belongs to the query string.
`alpha` is optional and belongs to the query string.
The `Server response` section shows HTTP status `200` and a `Response body` containing `true`.
Speaker says, "Naturally that's correct, the dataset belongs to us."
In this example, a successful ownership check is represented by a boolean `true` returned with status code 200.
The request has already been executed.
The server returns status `200`.
The speaker says, 'Remember, this tool just will verify data ownership. If you want to further trade your data, you can use other PIMCity components.'
The Data Provenance tool shown here verifies data ownership; it does not by itself handle the full further trading of data.
The user is referring to the demonstrated PIMCity Data Provenance component.
For the demonstrated tool in this clip.
The speaker says, "Then, for verification here you must use the same key, naturally."
For the watermark verification step to succeed, the `key` supplied to `/dp/wm/{queryId}` must be the same private key used when generating the watermark.
A watermark was generated using a private key.
The verification endpoint is called with that watermark-related hash.
For the demonstrated workflow, the same key must be reused at verification time.
The speaker says, "More than seven wouldn't work in this case."
If the file has seven URLs, choosing an `alpha` threshold greater than seven cannot yield a successful verification in the described all-seven-check scenario.
The dataset/file contains exactly seven URLs.
Verification requires counting successful URL checks against `alpha`.
In the seven-URL example, any threshold larger than seven is infeasible.
Speaker says, "Naturally that's correct, the dataset belongs to us."
The response body shown on screen is `true`.
The clip does not define the formal verification algorithm behind this conclusion.
When the verification endpoint returns `true`, the speaker interprets this as confirming that the dataset belongs to the requester.
The displayed response is from the watermark verification request.
The response body is `true`.
For the demonstrated request in this clip.
Speaker says, "In this manner we have demonstrated the data provenance tool by watermarking a file, verifying the file indeed belongs to that data owner."
The clip presents the workflow as a demonstration of a data provenance tool based on watermarking and ownership verification.
The shown Swagger request is part of the demonstrated workflow.
For the demonstrated tool usage in this clip.
The UI first expands 'POST /ipfs/dataset', then shows a selected file and a response containing 'Hash'.
The UI then expands 'GET /ipfs/dataset/{queryId}', fills the path parameter, executes, and shows the retrieved content.
The exact hash characters are not fully legible, but the sequence upload -> receive hash -> retrieve by that identifier is clear.
Open the POST endpoint '/ipfs/dataset' in the Swagger UI.
This endpoint is labeled 'Create new IPFS file'.
Select a local file for the request body field 'file string(binary)'.
The visible form accepts a binary file under multipart/form-data.
Execute the request and read the response body.
The successful response includes a JSON object with a 'Hash' field.
Use the returned identifier as 'queryId' in the GET endpoint '/ipfs/dataset/{queryId}'.
The GET endpoint description states it retrieves a file from IPFS by hash id.
Execute the GET request and inspect the response body.
The displayed body contains the retrieved file content, confirming the round trip.
The clip demonstrates a concrete two-step API workflow: upload a dataset to obtain an IPFS hash identifier, then retrieve the stored content using that identifier.
The screen scrolls from the GET IPFS response to the POST watermarking endpoint, executes it, then scrolls to the verification endpoint and fills its parameters.
The narration explicitly links the steps: use the same hash ID, send it to watermarking, obtain a new hash, then verify with two other parameters.
Start from the retrieved IPFS dataset response, where the original hash ID is already known from the GET call.
The speaker says to use "that same hash ID" after showing the GET response.
Call the POST endpoint `/ipfs/dataset/{queryId}` with the original IPFS hash to send it to the watermarking DP module.
The endpoint description and the executed request visibly use the original hash as `queryId`.
Read the response body and identify the returned `newHash` value.
The response JSON explicitly contains `"newHash":"QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm"`.
Move to the verification endpoint `/dp/wm/{queryId}` and use the `newHash` as the path `queryId`.
The speaker says the new hash will help verify the dataset, and the UI shows the verification endpoint accepting `queryId`.
Supply the private key array and set the threshold to seven for the seven-URL example.
These values are typed into the visible parameter fields before execution.
The demonstrated procedure chains three API operations: retrieve by IPFS hash, submit that hash to watermarking to obtain `newHash`, then verify ownership using `newHash`, the same private `key`, and an appropriate `alpha` threshold.
The `Curl` block shows `curl -X GET "https://easypims.pimcity-h2020.eu/provenance/dp/wm/QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;?key=-26&key=-52&key=8&key=60&key=76&key=61&key=-81&key=-13&key=-9&key=-106&key=-96&alpha=7" -H "accept: application/json"`.
The `Request URL` block repeats the same URL without the `curl` wrapper.
The exact internal meaning of each repeated `key` element is not explained in the clip.
The endpoint template places the dataset identifier in the path.
Visible in the Swagger operation header `GET /dp/wm/{queryId}`.
The base server URL and the concrete `queryId` value replace the path template.
Shown in the generated `Curl` and `Request URL` blocks.
The array parameter is serialized by repeating `key=` for each element, and the optional integer is appended as `alpha=7`.
Directly visible in the generated request string.
The UI converts the entered parameters into a single GET request URL with repeated `key` query fields and one `alpha` query field.
A file named 'sample_urls_seven.txt' is selected in the upload form.
The POST response body shows a JSON object including 'Name': 'sample_urls_seven.txt' and a 'Hash' field.
The GET response body displays multiple URL lines from the retrieved file.
The exact hash string is not fully reliable from the visible frames.
Some retrieved URL lines are partially obscured or inconsistently legible across frames.
Show how a local dataset file is uploaded to IPFS and then retrieved through the Data Provenance API.
A local text file named 'sample_urls_seven.txt' is available.
The Swagger UI exposes POST '/ipfs/dataset' and GET '/ipfs/dataset/{queryId}'.
Upload the file, obtain its hash identifier, and retrieve the stored content.
Expand POST '/ipfs/dataset' and choose the file 'sample_urls_seven.txt'.
The request body expects a binary file.
Execute the upload request.
This sends the selected file to the server.
Read the response body to obtain the returned 'Hash'.
The successful POST response includes the identifier for the stored file.
Expand GET '/ipfs/dataset/{queryId}' and enter the returned identifier into 'queryId'.
The GET endpoint retrieves a file from IPFS by hash id.
Execute the GET request and inspect the response body.
The body shows the retrieved text content, including URL lines.
The file is successfully uploaded and then retrieved by its hash identifier, demonstrating ownership-preserving storage access through the API.
The retrieved response body visibly contains the file contents after the upload step returned a matching identifier.
The speaker describes a file with seven URLs and says to set alpha threshold to seven to check seven out of seven.
The verification form shows `alpha` changed to `7` and the Execute button pressed.
The final verification response is not shown within the provided 120-second clip.
Given a dataset/file with seven URLs, configure the verification request so that success means all seven URLs are checked correctly and belong to the user.
The watermarking step produced `newHash` = `QmcA51TzAF1dwskvhXEhG7LBnqR26ampvkXsYCufFTxPdm`.
The verification endpoint is `/dp/wm/{queryId}`.
The private key is entered as an array of strings.
The file is stated to have seven URLs.
Choose the parameter values needed to verify that seven out of seven URLs are correct.
Use the `newHash` from the watermarking response as the verification path parameter.
The speaker says the new hash will help verify the dataset.
Enter the same private key used for watermark generation.
The narration states that verification must use the same key.
Set the threshold equal to the total number of URLs when requiring all seven to pass.
The speaker explicitly says to set alpha threshold to seven for seven out of seven.
Execute the GET verification request.
The cursor clicks Execute at the end of the clip.
The configured verification request uses `queryId` equal to the returned `newHash`, the listed private-key array, and `alpha = 7`.
The expected result is stated verbally as true if all seven URLs are correct and belong to the user; however, the actual response body is not visible before the clip ends.
The response area shows `Code 200` and `Response body true`.
Speaker says, "Response body is true. Naturally that's correct, the dataset belongs to us."
Execute a watermark verification request for the displayed dataset and inspect the server response.
`queryId = QmcAS1TZAF1dwsxhXEhG7LBnqR26amp;`
`key = [-26, -52, 8, 60, 76, 61, -81, -13, -9, -106, -96]`
`alpha = 7`
HTTP method `GET`
Determine the response body returned by the verification endpoint.
The request is sent using the displayed URL built from the form inputs.
Visible in the `Curl` and `Request URL` panels.
The server returns HTTP status code 200.
Shown under `Server response`.
The response body is the boolean value `true`.
Shown in the `Response body` panel and read aloud by the speaker.
The example request returns status `200` with response body `true`.
The speaker explicitly states that the result is correct because the dataset belongs to them.
A static slide titled 'PIMCity Demonstration' with subtitle 'BUILDING THE NEXT GENERATION PERSONAL DATA PLATFORMS' and section header 'Data Provenance' remains on screen.
The left side shows a green fingerprint icon labeled 'DATA PROVENANCE'; the right side contains descriptive text and three columns: 'Access the DP UI', 'Source Code', and 'Licence'.
Title banner
Fingerprint icon
Explanatory paragraph
Three information columns
No visual change occurs during this interval.
The slide content stays fixed while the narration explains the tool's purpose.
The visual functions as a static overview card while the audio supplies the conceptual framing of data provenance and watermarking.
The browser navigates from the slide to a Swagger UI page titled 'Data Provenance API Docs'.
Endpoint groups 'wm', 'urls', 'ipfs', and 'dataset' become visible as the page loads and scrolls.
Browser tab
Swagger header
Endpoint groups
The slide is replaced by the API documentation page.
The view scrolls to reveal endpoint categories.
The page remains an API documentation interface throughout.
This visual shift marks the move from conceptual explanation to operational demonstration.
The 'POST /ipfs/dataset' row is expanded.
A file picker opens and 'sample_urls_seven.txt' is selected.
The Execute button is pressed and a response panel appears with a JSON body containing 'Hash'.
The exact hash characters are not fully reliable from the visible frames.
POST endpoint panel
File input
Execute button
Response body
The endpoint expands.
A local file is chosen.
The request is executed.
The response displays a hash identifier.
The interface remains within the ipfs endpoint group.
The animation-like UI state changes demonstrate the first half of the storage workflow: turning a local file into an IPFS-addressed object.
The 'GET /ipfs/dataset/{queryId}' endpoint is expanded.
The 'queryId' field is filled with the identifier obtained earlier.
After execution, the response body shows retrieved text lines including URLs.
Some retrieved URL lines are partially obscured or inconsistently legible across frames.
GET endpoint panel
queryId input
Execute button
Response body
The GET endpoint expands.
The identifier is entered.
The request is executed.
The retrieved file content appears in the response.
The operation stays within the ipfs endpoint group.
This visual sequence demonstrates the second half of the workflow: using the stored identifier to recover the original dataset content.
The browser view scrolls through Swagger UI sections showing IPFS endpoints and then the watermarking POST endpoint.
Swagger UI page
GET `/ipfs/dataset/{queryId}` section
POST `/ipfs/dataset/{queryId}` section
endpoint descriptions
The view moves from a completed GET response to the list of IPFS endpoints.
The POST watermarking endpoint is selected and expanded.
The same base API documentation page remains on screen.
Endpoint names and descriptions stay visible while scrolling.
The visual sequence establishes the order of operations: first retrieve by hash, then send that hash to the watermarking module.
After clicking Execute on the POST endpoint, a response panel appears with JSON including `newHash`.
POST request panel
response body JSON
`newHash` field
The response area populates after execution.
The `newHash` string becomes visible and is highlighted by the speaker's commentary.
The request URL still contains the original IPFS hash as the path parameter.
This event shows that the watermarking step transforms the original IPFS hash into a new identifier used downstream.
The verification endpoint is opened and the fields `queryId`, `key`, and `alpha` are filled; `alpha` changes from 10 to 7 before Execute is clicked.
GET `/dp/wm/{queryId}` form
`queryId` input
`key` array input
`alpha` integer input
Execute button
`queryId` is pasted with the `newHash` value.
`key` is populated with a list of negative and positive integers as strings.
`alpha` is edited from the default `10` to `7`.
The Execute button is pressed at the end.
The endpoint remains `/dp/wm/{queryId}` throughout the form filling.
The animation demonstrates the concrete input structure required for verification and the threshold choice tied to the seven-URL example.
The screen is scrolled to the lower part of the Swagger operation, showing `Curl`, `Request URL`, `Server response`, `Response body`, and `Response headers`.
`Curl` block
`Request URL` block
`Server response` section
`Response body` panel
`Response headers` panel
The mouse cursor moves near the response area while the displayed response remains `true`.
Status code stays `200`.
Response body stays `true`.
This view documents the outcome of the executed verification request rather than the input form itself.
The page scrolls upward from the response section to the parameter form.
The `Parameters` table becomes fully visible with `queryId`, `key`, and `alpha`.
Swagger operation header
`Parameters` table
input fields for `queryId`, `key`, and `alpha`
The viewport moves upward.
The request inputs replace the response panels as the main focus.
The same endpoint `/dp/wm/{queryId}` remains open.
The previously entered values remain visible.
The visual transition links the returned result back to the exact inputs that produced it.
The page scrolls downward again, the cursor hovers over the `Download` button, and then the view scrolls up to the page title.
The title area reads `Swagger`, `Data Provenance API Docs`, `alpha0.3`, `OAS3`, and `Sample REST API documentation`.
Speaker says, "And if we wish to, downloading the file from the Swagger API tool itself. Thank you."
No actual downloaded file contents are shown after hovering over `Download`.
`Download` button
page title banner
server selector
The viewport moves down to the response controls.
The cursor points at `Download`.
The viewport moves up to the document header.
The same API documentation page remains in view.
The server URL stays `https://easypims.pimcity-h2020.eu/provenance`.
The ending emphasizes that the Swagger interface can also be used to retrieve the file, then closes by showing the overall API documentation context.
The speaker explicitly says the tool 'just will verify data ownership' and that other PIMCity components are needed to 'further trade your data'.
One might assume the demonstrated Data Provenance tool itself conducts the entire data marketplace transaction.
The video states that this component verifies ownership; broader trading requires other PIMCity components.
The speaker says, "Note, we do not record private keys for the time being and due to privacy reasons... you have to provide us with the private key, or else we will generate one for you on the fly."
One might assume the watermarking service retains the private key for later automatic verification.
The video explicitly states that private keys are not recorded for privacy reasons; the user must provide the same key again, or the system may generate one on the fly during watermark creation.
The speaker says alpha could be set less than or equal to seven, and that more than seven would not work in this case.
Increasing `alpha` beyond the number of URLs may seem safer, but it can make verification impossible.
For a file with seven URLs, the maximum meaningful threshold in the all-seven-check scenario is seven; values above seven cannot be satisfied.
The narration only summarizes the workflow as watermarking and verification.
The screen shows API inputs and outputs but no internal verification formula or proof.
One might infer from the clip that the underlying watermark verification mathematics is fully shown.
The video demonstrates request parameters, generated URL, and boolean response only; it does not present the verification algorithm, proof, or error model.
The narration introduces the tool's purpose before the screen changes to the demonstrator.
The slide gives way to the Swagger API page.
The abstract purpose of watermarking and ownership verification is applied through the concrete Swagger API interface.
The POST response provides a 'Hash' that is then used in the GET path parameter.
Retrieval by identifier depends on a prior successful upload that produced the identifier.
The same identifier appears in the POST response and then in the GET request URL.
The exact characters of the hash are not fully reliable from the visible frames.
In the demonstrated workflow, the returned hash serves as the queryId used to retrieve the stored file.
The speaker says to use the same hash ID to go to a new endpoint.
The UI moves from the GET response to the POST watermarking endpoint.
The IPFS hash obtained or used in the retrieval step is directly reused as the input to the watermarking POST endpoint.
The POST response contains `newHash`.
The speaker says this new hash will help verify the dataset.
The `newHash` produced by the watermarking step becomes the `queryId` for the verification endpoint.
The speaker ties the seven-URL example to setting `alpha` to seven.
The threshold rule is part of how the verification endpoint is configured in the demonstrated workflow.
The operation header `GET /dp/wm/{queryId}` is directly followed by the `Parameters` table listing `queryId`, `key`, and `alpha`.
The endpoint definition includes the parameter schema needed to issue the verification request.
The generated `Curl` and `Request URL` contain the same values later shown in the parameter form.
The response section displays `200` and `true` for that request.
The displayed parameter values are applied to the verification endpoint, producing the shown boolean result.
Speaker connects `Response body is true` with `the dataset belongs to us`.
The ownership interpretation depends on the observed boolean response from the verification call.
The opening narration explains the tool's purpose.
The slide title and paragraph define Data Provenance.
The speaker discusses monetizing, sharing, and verifying ownership of browsing datasets.
The POST '/ipfs/dataset' panel and file selection are visible.
The GET '/ipfs/dataset/{queryId}' panel and response body are visible.
The speaker limits the tool to ownership verification.
Endpoint text `Get a file from IPFS by hash id` is visible.
Response body shows `newHash` after the POST request.
The speaker says verification must use the same key.
The speaker explains setting alpha threshold to seven for seven URLs.
The parameter table labels `queryId` as `string (path)` with a visible IPFS-like value.
The generated URL repeats `key=` for each array element.
Speaker says the response body is true and that the dataset belongs to them.
Covered · Static introductory slide with spoken explanation of the Data Provenance tool, its watermarking purpose, and its scope limitation.
Covered · Navigation to the Swagger UI and overview of visible endpoint groups.
Covered · Expansion of POST '/ipfs/dataset', file selection, execution, and receipt of a hash identifier.
Covered · Expansion of GET '/ipfs/dataset/{queryId}', entry of the identifier, execution, and display of retrieved content.
Covered · The speaker transitions verbally toward watermarking the retrieved file, but no new mathematical or procedural content is shown before the clip ends.
Covered · Shows the GET IPFS retrieval result and introduces reuse of the same hash ID.
Covered · Demonstrates the POST watermarking endpoint and the returned `newHash`.
Covered · Fills the verification endpoint parameters and explains the seven-URL threshold choice; the final response is not shown within the clip.
Covered · The clip shows the executed request output: status 200, response body true, and the generated URL.
Covered · The view scrolls up to the parameter form while the narrator explains the demonstration purpose.
Covered · The page scrolls down to the `Download` control and then up to the API documentation title while the speaker closes the demo.
Reviewed English material v1: card "Purpose of the Data Provenance tool" at 0:00 — The video presents Data Provenance as a tool for watermarking personal data so that ownership can be verified later. The narration specifically frames this around datasets such as browsing data that the owner may want to share, spread among colleagues, or monetize.
Continue with related videos in the same subject.
YouTube8:13
YouTube6:03
YouTube5:16