14:36:20 <RRSAgent> RRSAgent has joined #lws
14:36:24 <RRSAgent> logging to https://www.w3.org/2026/01/12-lws-irc
14:49:29 <elf-pavlik> elf-pavlik has joined #lws
14:49:58 <acoburn> acoburn has joined #lws
14:50:27 <acoburn> zakim, start meeting
14:50:27 <Zakim> RRSAgent, make logs Public
14:50:29 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:50:35 <acoburn> meeting: Linked Web Storage
14:51:05 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260112T100000/#agenda
14:51:05 <agendabot> clear agenda
14:51:05 <agendabot> agenda+ Introductions & Announcements
14:51:05 <agendabot> agenda+ Initial CRUD with proposed metadata handling (PR -> #37 https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260112T100000/github.com/w3c/lws-protocol/pull/37 )
14:51:05 <agendabot> agenda+ Storage Description Resource (PR -> #53 https://github.com/w3c/lws-protocol/pull/53 )
14:51:05 <agendabot> agenda+ Security & Privacy Considerations (PRs -> #50 https://github.com/w3c/lws-protocol/pull/50 & -> #49 https://github.com/w3c/lws-protocol/pull/49 )
14:51:07 <agendabot> agenda+ Replace "absolute URI" with "URI (PR -> #48 https://github.com/w3c/lws-protocol/pull/48 )
14:51:18 <acoburn> RRSAgent, make minutes
14:51:19 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/12-lws-minutes.html acoburn
14:54:45 <laurens> laurens has joined #lws
14:56:44 <TallTed> TallTed has joined #lws
14:57:25 <eBremer> eBremer has joined #lws
15:00:09 <gibsonf1> gibsonf1 has joined #lws
15:00:15 <pchampin> RRSAgent
15:00:15 <gibsonf1> present+
15:00:24 <eBremer> present+
15:00:30 <acoburn> present+
15:00:33 <laurens> present+
15:00:36 <laurens> chair: laurens
15:00:43 <pchampin> present+
15:00:51 <pchampin> s/RRSAgent/
15:01:40 <acoburn> previous meeting: https://www.w3.org/2026/01/05-lws-minutes.html
15:01:42 <Beau> Beau has joined #lws
15:01:45 <ryey> ryey has joined #lws
15:01:48 <Beau> present+
15:03:04 <TallTed> present+
15:03:23 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/12-lws-minutes.html TallTed
15:03:45 <acoburn> scribenick: acoburn
15:04:04 <acoburn> zakim, open agendum 1
15:04:04 <Zakim> agendum 1 -- Introductions & Announcements -- taken up [from agendabot]
15:04:36 <acoburn> matthieu: currently work at ODI, worked on some solid specs
15:04:46 <ryey> present+
15:05:06 <Luke> Luke has joined #lws
15:05:12 <laurens> q?
15:05:16 <acoburn> zakim, open agendum 2
15:05:16 <Zakim> agendum 2 -- Initial CRUD with proposed metadata handling (PR -> #37
15:05:17 <Zakim> ... https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260112T100000/github.com/w3c/lws-protocol/pull/37 ) -- taken up [from agendabot]
15:06:00 <acoburn> laurens: PR by ebremer. Has been discussed since mid-Nov
15:06:15 <gibsonf1> q+ to ask about subject issue for 37
15:06:16 <acoburn> eBremer: since last meeting, rebasing to make reviewing easier
15:06:26 <laurens> q?
15:06:30 <laurens> ack next
15:06:30 <acoburn> ack next
15:06:31 <Zakim> gibsonf, you wanted to ask about subject issue for 37
15:06:41 <dmitriz> dmitriz has joined #lws
15:06:41 <bendm> bendm has joined #lws
15:07:02 <acoburn> gibsonf: wrote about the use of subject resources and potential changes
15:07:15 <acoburn> ... simple way uses a query string with subject URI
15:07:24 <laurens> q?
15:07:26 <gibsonf1> https://github.com/w3c/lws-protocol/pull/37#issuecomment-3733267091
15:07:26 <gb> https://github.com/w3c/lws-protocol/pull/37 -> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
15:07:55 <acoburn> tallted: I have not been able to review, some more time would be nice
15:08:26 <acoburn> laurens: should we postpone to next meeting
15:08:43 <acoburn> ebremer: Fred's suggestion relates to query
15:08:45 <pchampin> q+
15:09:02 <uvdsl> uvdsl has joined #lws
15:09:16 <acoburn> gibsonf1: this is not about query, it's about CRUD operations on subject resources
15:09:41 <acoburn> ... esp subject resources that are outside the domain of a storage
15:10:14 <acoburn> ... idea is to qualify reads and writes to a particular URI
15:10:21 <uvdsl> present+
15:11:16 <Luke> present+
15:11:23 <ericP> ericP has joined #lws
15:11:24 <acoburn> laurens: I see use cases, but shouldn't be a separate use case. This may be more complicated than introducing a query param. Impact may be broader
15:11:31 <ericP> present+
15:11:36 <laurens> q?
15:11:36 <acoburn> ... also relates to authZ/authN
15:11:55 <acoburn> gibsonf1: this has big implications for interop
15:11:55 <laurens> ack pchampin
15:12:01 <bendm> present+
15:12:15 <acoburn> pchampin: we seem not to be talking about the same thing
15:12:27 <acoburn> ... fred talks about resources in the broad (RDF) sense
15:12:50 <acoburn> ... e.g. subject URIs that are outside the domain of a storage
15:12:55 <laurens> q+
15:13:01 <acoburn> ... however, the proposed changes are not necessary
15:13:18 <acoburn> ... the resources described in this PR are Information Resources contained in a storage
15:13:44 <acoburn> ... this allows RDF files to be added to a storage with any subject
15:14:15 <acoburn> ... thus, retrieval of a subject resource requires some form of query
15:15:00 <acoburn> gibsonf1: one can put arbitrary triples in files in a storage
15:15:08 <pchampin> by "file" I meant "information resource": some content that I can retrieve by dereferncing a the URI; I'm not assuming it is stored as a file on the server
15:16:09 <laurens> q?
15:16:22 <acoburn> ... but this is unhelpful if I want to give access to a ??? resource to someone else
15:17:10 <Luke> q+
15:17:21 <laurens> q?
15:17:24 <pchampin> q+
15:18:16 <acoburn> laurens: LWS is defining crud operations on information resources, I fail to see how a LWS server could display information resources that are out of domain of a storage
15:18:42 <acoburn> ... I fail to see how adding query params would fix this
15:18:46 <laurens> ack laurens
15:19:32 <acoburn> gibsonf1: in terms of files, these subject resources can be anywhere, but how do I find this information?
15:19:48 <acoburn> laurens: "how do I find something" is query
15:19:54 <acoburn> ... and discovery
15:20:24 <laurens> q?
15:20:41 <acoburn> gibsonf1: an information resource may be prefixed with an LWS URI
15:20:55 <acoburn> ... this would be very limited
15:21:28 <laurens> ack Luke
15:22:14 <acoburn> luke: would like clarification -- how does the linking work?
15:22:47 <acoburn> gibsonf1: I would like to be able to have something more than just a google drive-like interface
15:22:58 <acoburn> q+ to talk about scope of LWS
15:23:34 <acoburn> luke: this seems like something else
15:23:36 <pchampin> q-
15:23:38 <TallTed> q+
15:24:02 <acoburn> gibson: the response provides the triples with a particular subject URI
15:24:13 <matthieubosquet> matthieubosquet has joined #lws
15:24:41 <laurens> ack acoburn
15:24:41 <Zakim> acoburn, you wanted to talk about scope of LWS
15:24:47 <laurens> scribe+
15:25:01 <laurens> acoburn: I think we're talking about a couple of different layers
15:25:20 <laurens> ... any implementation that uses specifications is going to combine many different specs.
15:25:35 <laurens> ... A specification isn't going to encompass the entire implementation.
15:25:55 <laurens> ... LWS tries to be really specific about that low level of information resource and CRUD on that resource.
15:26:03 <laurens> ... The content of that resource is a different layer.
15:26:18 <laurens> ... The content could be RDF, JSON, XML, ...
15:26:40 <laurens> ... In Fred's case he could use another specification on top of LWS, like SPARQL.
15:26:54 <laurens> ... This could result in the merging of a triple store and LWS server.
15:27:08 <gibsonf1>                  q+ to respond
15:27:14 <laurens> ... If SPARQL isn't the right thing, QPF or TPF could be the solution perhaps.
15:27:40 <laurens> ... In LWS we want to define the low level information resource.
15:27:42 <laurens> scribe-
15:27:45 <laurens> ack gibsonf1
15:27:51 <laurens> ack gibsonf
15:27:51 <Zakim> gibsonf, you wanted to respond
15:27:57 <acoburn> gibsonf1: not talking about the content, rather the address
15:28:11 <laurens> ack TallTed
15:28:32 <dmitriz> I think it might help to use example URLs in this discussion..
15:28:45 <acoburn> tallted: if I'm writing to my storage, there will be a location of the storage, represented by a URI
15:29:20 <acoburn> ... there are objects in that storage, e.g., documents or something that resembles a database
15:29:35 <acoburn> ... a filesystem can be conceived as a database of a kind
15:30:00 <acoburn> ... the issue EricP was discussing related to misunderstanding of the technologies at hand
15:30:19 <acoburn> ... i.e. a preceived need to give every protein a localized URI
15:30:57 <acoburn> ... in that case, a relative uri was used. Using those different identifiers for the same protein can be useful
15:31:43 <acoburn> ... each entity is different, but each refers to the same protein. You can use own:sameAs to make use of this
15:31:58 <gibsonf1> q+ to talk about sameas
15:32:03 <acoburn> s/own:sameAs/owl:sameAs/
15:32:39 <acoburn> tallted: using sameAs allows us to talk about many different entities as if they are the same
15:33:22 <acoburn> tallted: this is like referring to Ted using various different identifiers, all of which refer to the same individual
15:33:47 <acoburn> ... having the multiple names are helpful because I can then list all the names I want, excluding those I don't want
15:34:31 <acoburn> ... understand Fred's use case, this seems to be asking for a query that includes the entity identifier and get the information from
15:34:43 <laurens> q?
15:34:51 <acoburn> ... all the resources the include that subject resource
15:35:33 <acoburn> ... what you're asking for is the magic for how those subject identifiers are all associated
15:35:48 <gb> https://github.com/w3c/lws-ucs/issues/215 -> Issue 215 [UC] Mechanism to access a resource identifier in a storage with identifier that points to a different storage (by gibsonf1) [triage] [usecase]
15:36:15 <acoburn> ... In that case, Fred needs to know all the places where a particular subject resource is referenced
15:36:53 <acoburn> ... in order for that to work, if the software needs to do that, it is very complicated for software. It will require a lot of computational
15:37:01 <acoburn> ... resources
15:37:22 <laurens> q?
15:37:23 <acoburn> ... realistically, it becomes intractable
15:37:40 <laurens> ack gibsonf
15:37:40 <Zakim> gibsonf, you wanted to talk about sameas
15:38:06 <acoburn> gibsonf: I'm talking about anyone who stores information with a subject URI
15:38:14 <TallTed> q+
15:38:38 <acoburn> ... i.e. a scientist can request all examples with a common subject URI
15:38:48 <eBremer> q+
15:39:03 <laurens> ack TallTed
15:39:16 <laurens> q+
15:39:45 <acoburn> tallted: Fred is talking about a limited application of lookup magic. I.e., given a URI, go to N storages and merge the data
15:39:57 <acoburn> ... this is a small kind of magic, but it is still magic
15:40:26 <laurens> q?
15:40:33 <acoburn> ... this is the general idea of linked web storage, but there is a lot of magic involved
15:41:21 <acoburn> q+ to ask for a straw poll for whether Fred's case should be in scope or not
15:41:39 <acoburn> ... we have discussed this for several weeks but haven't made headway
15:41:41 <laurens> ack eBremer
15:42:02 <laurens> q-
15:42:16 <acoburn> eBremer: I believe I am following what Fred is saying, and we have similar use cases
15:42:46 <acoburn> ... e.g., different users need access to different resources & URIs
15:42:56 <gibsonf1> q+ to ask super brief
15:42:56 <laurens> q?
15:43:02 <acoburn> ... would like to talk further
15:43:55 <dmitriz> could we do a special topic call on this?
15:44:15 <matthieubosquet7> matthieubosquet7 has joined #lws
15:44:18 <dmitriz> haha true
15:44:56 <laurens> q?
15:44:58 <pchampin> +1 to separate the "in scope for CRUD" and "in scope for LWS"
15:45:09 <pchampin> q-
15:45:16 <acoburn> laurens: we could decide whether it is in or out of scope of CRUD
15:45:19 <gibsonf1> q-
15:45:26 <acoburn> q-
15:45:35 <dmitriz> -1 (out of scope with CRUD, in scope with a separate query feature)
15:45:49 <acoburn> STRAW POLL: is Fred's feature in scope for CRUD?
15:45:54 <gibsonf1> +1
15:45:57 <acoburn> -1
15:45:59 <matthieubosquet> -1
15:45:59 <pchampin> -1
15:45:59 <Luke> -1
15:46:04 <laurens> -1
15:46:04 <eBremer> -1
15:46:14 <ryey> -1
15:46:15 <TallTed> -1 (out of scope for CRUD; in scope for LWS; will be implementable by chunks of CRUD and other)
15:46:20 <bendm> bendm has joined #lws
15:46:23 <ericP> -1 but willing to consider a detailed technical write-up
15:46:36 <laurens> https://github.com/w3c/lws-ucs/issues/215
15:46:36 <gb> https://github.com/w3c/lws-ucs/issues/215 -> Issue 215 [UC] Mechanism to access a resource identifier in a storage with identifier that points to a different storage (by gibsonf1) [triage] [usecase]
15:47:07 <laurens> q?
15:47:09 <acoburn> laurens: most see this as out of scope for CRUD, we can discuss further in the open issue
15:47:45 <acoburn> ... we will try to resolve PR 37 to next week. Please review by next week
15:48:04 <acoburn> zakim, open agendum 3
15:48:04 <Zakim> agendum 3 -- Storage Description Resource (PR -> #53 https://github.com/w3c/lws-protocol/pull/53 ) -- taken up [from agendabot]
15:48:12 <laurens> scribe+
15:48:25 <laurens> acoburn: This is a PR that has been open for a couple of weeks.
15:48:36 <laurens> ... Shortly before this meeting only ryey had comments.
15:48:45 <laurens> ... I don't think we can vote on this today.
15:49:05 <laurens> ... This is a way of defining a particular resource in a storage that defines capabilities and extension points.
15:49:22 <laurens> ... For example if the storage has a notification service, SPARQL endpoint, support for binary patch, ...
15:49:39 <laurens> ... It is a way of adding capability and endpoint discovery to storage in an interoperable way.
15:49:54 <dmitriz> q+
15:50:03 <laurens> ... Are there other comments? I assume we cannot proceed to a vote today.
15:50:07 <laurens> scribe-
15:51:04 <laurens> scribe+
15:51:05 <laurens> dmitriz: Why add one more layer of indirection for the capabilities
15:51:13 <pchampin> q+ to ask what would that level of indirection buy us
15:51:15 <laurens> acoburn: Why not have both?
15:51:27 <laurens> ... A lot of linked data systems are already pretty chatty.
15:51:41 <laurens> ... But I am not opposed to having a storage description have a linkset.
15:51:56 <laurens> dmitriz: I think that is exactly the reason to have a linkset.
15:52:39 <laurens> acoburn: dmitriz would you be able to write up in the PR what that might look like?
15:52:46 <laurens> ack pchampin
15:52:46 <Zakim> pchampin, you wanted to ask what would that level of indirection buy us
15:52:54 <laurens> ack dmitriz
15:53:03 <acoburn> pchampin: what problem does this indirection solve?
15:53:09 <laurens> pchampin: I don't really see what this level of indirection will get us.
15:53:17 <gibsonf1> q+ to ask why not just have a uri for the storage itself to use to get information about the storage itself?
15:53:45 <acoburn> ... perhaps the binding between the data model and the specific media type can be made more explicit
15:53:54 <laurens> scribe-
15:54:00 <laurens> ack gibsonf1
15:54:11 <acoburn> gibsonf1: is there a unique URI for a storage?
15:54:15 <laurens> ack gibsonf
15:54:15 <Zakim> gibsonf, you wanted to ask why not just have a uri for the storage itself to use to get information about the storage itself?
15:54:31 <laurens> scribe+
15:54:52 <laurens> acoburn: Historically the root of a storage (the storage URI) becomes a container.
15:55:09 <laurens> ... If you want to give access to that root container, you are perhaps giving broad access to the storage.
15:55:15 <gibsonf1> q+ to ask to not conflate a root container with the LWS storage uri
15:55:18 <laurens> ... With this resource the intent is for it to be public.
15:55:33 <laurens> ... It gives details pertaining to how you might request access.
15:55:44 <laurens> ... Its authorization is different to the root of the storage.
15:55:46 <laurens> scribe-
15:56:15 <acoburn> gibsonf1: conflating a root container with a storage URI causes trouble
15:56:30 <pchampin> q+
15:56:33 <laurens> ack gibsonf
15:56:33 <Zakim> gibsonf, you wanted to ask to not conflate a root container with the LWS storage uri
15:56:41 <laurens> ack pchampin
15:57:17 <acoburn> pchampin: the example seems to imply that the URI suggests a root container, but there is nothing normatively that requires this
15:57:42 <acoburn> ... also, there is nothing that prevents the description being the same as the root URI
15:57:47 <laurens> q?
15:57:50 <gibsonf1> why would storage desciprion uri be different that storage uri
15:58:34 <acoburn> rrsagent, make minutes
15:58:35 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/12-lws-minutes.html acoburn
15:58:55 <pchampin> gibsonf1 I agree that it might not be necessary in most cases... the storage description is a "representation" (in REST terms) of the storage
15:59:05 <acoburn> laurens: we will continue discussing Fred's use case in the related issue
15:59:12 <acoburn> ... we can close off for today
15:59:24 <acoburn> rrsagent, draft minutes
15:59:25 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/12-lws-minutes.html acoburn
16:00:06 <acoburn> acoburn has left #lws