Meeting minutes
Introductions & Announcements
matthieu: currently work at ODI, worked on some solid specs
Initial CRUD with proposed metadata handling (PR #37 )
laurens: PR by ebremer. Has been discussed since mid-Nov
eBremer: since last meeting, rebasing to make reviewing easier
<Zakim> gibsonf, you wanted to ask about subject issue for 37
gibsonf: wrote about the use of subject resources and potential changes
… simple way uses a query string with subject URI
<gibsonf1> w3c/
<gb> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
tallted: I have not been able to review, some more time would be nice
laurens: should we postpone to next meeting
ebremer: Fred's suggestion relates to query
gibsonf1: this is not about query, it's about CRUD operations on subject resources
… esp subject resources that are outside the domain of a storage
… idea is to qualify reads and writes to a particular URI
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
… also relates to authZ/authN
gibsonf1: this has big implications for interop
pchampin: we seem not to be talking about the same thing
… fred talks about resources in the broad (RDF) sense
… e.g. subject URIs that are outside the domain of a storage
… however, the proposed changes are not necessary
… the resources described in this PR are Information Resources contained in a storage
… this allows RDF files to be added to a storage with any subject
… thus, retrieval of a subject resource requires some form of query
gibsonf1: one can put arbitrary triples in files in a storage
<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
gibsonf1: but this is unhelpful if I want to give access to a ??? resource to someone else
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
… I fail to see how adding query params would fix this
gibsonf1: in terms of files, these subject resources can be anywhere, but how do I find this information?
laurens: "how do I find something" is query
… and discovery
gibsonf1: an information resource may be prefixed with an LWS URI
… this would be very limited
luke: would like clarification -- how does the linking work?
gibsonf1: I would like to be able to have something more than just a google drive-like interface
luke: this seems like something else
gibson: the response provides the triples with a particular subject URI
<Zakim> acoburn, you wanted to talk about scope of LWS
acoburn: I think we're talking about a couple of different layers
… any implementation that uses specifications is going to combine many different specs.
… A specification isn't going to encompass the entire implementation.
… LWS tries to be really specific about that low level of information resource and CRUD on that resource.
… The content of that resource is a different layer.
… The content could be RDF, JSON, XML, ...
… In Fred's case he could use another specification on top of LWS, like SPARQL.
… This could result in the merging of a triple store and LWS server.
… If SPARQL isn't the right thing, QPF or TPF could be the solution perhaps.
… In LWS we want to define the low level information resource.
<Zakim> gibsonf, you wanted to respond
gibsonf1: not talking about the content, rather the address
<dmitriz> I think it might help to use example URLs in this discussion..
tallted: if I'm writing to my storage, there will be a location of the storage, represented by a URI
… there are objects in that storage, e.g., documents or something that resembles a database
… a filesystem can be conceived as a database of a kind
… the issue EricP was discussing related to misunderstanding of the technologies at hand
… i.e. a preceived need to give every protein a localized URI
… in that case, a relative uri was used. Using those different identifiers for the same protein can be useful
… each entity is different, but each refers to the same protein. You can use owl:sameAs to make use of this
tallted: using sameAs allows us to talk about many different entities as if they are the same
tallted: this is like referring to Ted using various different identifiers, all of which refer to the same individual
… having the multiple names are helpful because I can then list all the names I want, excluding those I don't want
… understand Fred's use case, this seems to be asking for a query that includes the entity identifier and get the information from
… all the resources the include that subject resource
… what you're asking for is the magic for how those subject identifiers are all associated
<gb> Issue 215 [UC] Mechanism to access a resource identifier in a storage with identifier that points to a different storage (by gibsonf1) [triage] [usecase]
tallted: In that case, Fred needs to know all the places where a particular subject resource is referenced
… 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
… resources
… realistically, it becomes intractable
<Zakim> gibsonf, you wanted to talk about sameas
gibsonf: I'm talking about anyone who stores information with a subject URI
… i.e. a scientist can request all examples with a common subject URI
tallted: Fred is talking about a limited application of lookup magic. I.e., given a URI, go to N storages and merge the data
… this is a small kind of magic, but it is still magic
… this is the general idea of linked web storage, but there is a lot of magic involved
… we have discussed this for several weeks but haven't made headway
eBremer: I believe I am following what Fred is saying, and we have similar use cases
… e.g., different users need access to different resources & URIs
… would like to talk further
<dmitriz> could we do a special topic call on this?
<dmitriz> haha true
<pchampin> +1 to separate the "in scope for CRUD" and "in scope for LWS"
laurens: we could decide whether it is in or out of scope of CRUD
<dmitriz> -1 (out of scope with CRUD, in scope with a separate query feature)
STRAW POLL: is Fred's feature in scope for CRUD?
<gibsonf1> +1
<acoburn> -1
<matthieubosquet> -1
<pchampin> -1
<Luke> -1
<laurens> -1
<eBremer> -1
<ryey> -1
<TallTed> -1 (out of scope for CRUD; in scope for LWS; will be implementable by chunks of CRUD and other)
<ericP> -1 but willing to consider a detailed technical write-up
<laurens> w3c/
<gb> Issue 215 [UC] Mechanism to access a resource identifier in a storage with identifier that points to a different storage (by gibsonf1) [triage] [usecase]
laurens: most see this as out of scope for CRUD, we can discuss further in the open issue
… we will try to resolve PR 37 to next week. Please review by next week
Storage Description Resource (PR #53 )
acoburn: This is a PR that has been open for a couple of weeks.
… Shortly before this meeting only ryey had comments.
… I don't think we can vote on this today.
… This is a way of defining a particular resource in a storage that defines capabilities and extension points.
… For example if the storage has a notification service, SPARQL endpoint, support for binary patch, ...
… It is a way of adding capability and endpoint discovery to storage in an interoperable way.
… Are there other comments? I assume we cannot proceed to a vote today.
dmitriz: Why add one more layer of indirection for the capabilities
acoburn: Why not have both?
… A lot of linked data systems are already pretty chatty.
… But I am not opposed to having a storage description have a linkset.
dmitriz: I think that is exactly the reason to have a linkset.
acoburn: dmitriz would you be able to write up in the PR what that might look like?
<Zakim> pchampin, you wanted to ask what would that level of indirection buy us
pchampin: what problem does this indirection solve?
pchampin: I don't really see what this level of indirection will get us.
… perhaps the binding between the data model and the specific media type can be made more explicit
gibsonf1: is there a unique URI for a storage?
<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?
acoburn: Historically the root of a storage (the storage URI) becomes a container.
… If you want to give access to that root container, you are perhaps giving broad access to the storage.
… With this resource the intent is for it to be public.
… It gives details pertaining to how you might request access.
… Its authorization is different to the root of the storage.
gibsonf1: conflating a root container with a storage URI causes trouble
<Zakim> gibsonf, you wanted to ask to not conflate a root container with the LWS storage uri
pchampin: the example seems to imply that the URI suggests a root container, but there is nothing normatively that requires this
… also, there is nothing that prevents the description being the same as the root URI
<gibsonf1> why would storage desciprion uri be different that storage uri
<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
laurens: we will continue discussing Fred's use case in the related issue
… we can close off for today