Meeting minutes
Introduction & Announcements
lukedary: I work for RedHat; new to the Solid community
Open Pull Requests
acoburn: a number of open PRs. Some simple, some non-simple ones. I'll leave the editorial ones open, but they will be merged soon
… the next two (#49, #50) are related to authorization. they are not editorial. if there are concerns, we can discuss. I'll leave them open for a few days.
<gb> Pull Request 49 Consolidate privacy considerations (by acoburn)
<gb> Pull Request 50 Consolidate security considerations (by acoburn)
acoburn: Ted, you mentioned that URI, as defined by IETF, is absolute, so "absolute URI" is redundent
… this also prevents relative URIs
CRUD And Metadata handling
TallTed: let's keep this async [in git comments)
acoburn: we had general agreement before the break and agreed to vote today
… any reason to defer to later?
[crickets]
acoburn: any discussion before voting?
TallTed: github pushed updates to the PR comments in such a way we can't review [linewise]
<dmitriz> yeah, I wonder if the commits can be compressed, and PR can be re-opened
eBremer: i initially broke this up into separate folder but it accumulated commits because the target document moved
acoburn: rebase and force-push?
eBremer: wilco
<Zakim> gibsonf, you wanted to ask about containers and patch
gibsonf1: q's on the nature of storage: isn't the storage itself the root container?
<dmitriz> I think the difference is - the storage _has_ a root container, not is
gibsonf1: bigger issue: what if i want to write RDF data to the storage w/o putting it in a container?
… e.g. stuff about a wikidata id as a subject?
… closely related to PATCH
… PATCH is used to create events on a server but not in a container
TallTed: RDF, by its nature, is multiple layers of abstract in itself.
… you can't put anything NOT into a container
just because it's invisible to you doesn't mean it isn't there.
á la writing to a [disk] volume w/o knowing there's a volume
… best to take them as freebies
dmitriz: agree with the complexities that TallTed mentioned
… can we sidestep this by refering to containers w/o a trailing '/' and the root w a trailing '/'?
acoburn: at Ghent, we discussed avoiding any semantics in the URI; placing everything in link headers
<Zakim> gibsonf, you wanted to ask about containers and respond
dmitriz: makes sense but my proposal holds; URI1 for storage w '/'...
gibsonf1: not everything we have is a file-system-based container. we have predicates which create the hierarchy of containers
… i think the "file storage container" (w '/') and a "container" (w/o '/') works
… resolving this allows me to discriminate a subject URI from a request URI
acoburn: suppose we have foo.storage and bar.storage. in foo, we have a resource that describes bar.storage
gibsonf1: yeah, maybe easiest to think of the mass of wikidata URIs that you might want to describe
acoburn: i think we have to be careful about who is authoritative
acoburn: i'm writing some stuff about Anchorage
… you update that saying that I live in NYC. who's authoritative?
… i argue this is not specific to LWS
gibsonf1: i think the storage itself is a claim on who's authoritative
… if i want to make a req FROM MY STORAGE about some city...
<Zakim> ericP, you wanted to talk about Bio2RDF
<TallTed> lots of owl:sameAs reasoning that's *right*, as opposed to many owl:sameAs statements in the wild
ericP: Bio2RDF provided a mechanism to supplemnt e.g. UniProt proteins. The prob was that the ID for your version of proteinX was local and therefor necessarily different from UniProt's proteinX so the none of the graphs touched on proteinX
gibsonf1: right, the graphs don't merge
acoburn: we have this problem today in RDF
… i think you're getting at the issue of query
gibsonf1: you're talking about an RDF file that can have lots of stuff in it
… i'm talking about the case where i want to store/retrieve data that's got an external (natural) URI
… i don't want to fall back to a glorified RDF file system
TallTed: it sounds like you're taking the guidance that's been written as a forbidance from doing what you've been doing
… i explain RDF to folks using a primary key as a subject identifier and headings and cell values as the predicate and object
… it's useful to put the info in those tables into files
… experts can profit from abstraction layers, even if you know it down to the atoms
… that's part of why we keep these folders around
<pchampin> arriving now
<Zakim> gibsonf, you wanted to respond
gibsonf1: not saying the files, turtle and spreadsheets aren't great.
… just want to make it natural for folks who have subjects in their storage, that they can find their local info
acoburn: i'd like to center this about the PR which has CRUD operations
… you're talking about query which i want to keep separate from CRUD operations
<TallTed> CRUD -> Read == Query :-)
acoburn: we have another group to talk about type indexes, and by extension, query
gibsonf1: not query, it's about creating and referring to a URI in my storage
acoburn: OK, but it is a significant departure from SoLID (so far)
<TallTed> PUT/POST resource_x ; GET resource_y ; PATCH resource_x ; DELETE resource_y
<gibsonf1> foo.storage&subject=uri
<TallTed> (canonical capitalization of Solid is now Solid. "SOcial LInked Data" has been discarded as confusing and limiting.)
ericP: i propose that gibsonf1 write up an architure doc that describes how we can use a URI to refer both to wikidata's WWII and gibsonf1.solid WWII
gibsonf1: thinking just gibsonf1.solid/?query=wikidata.org/WWII
acoburn: careful, "simple" might not be universal...
Storage Description Resource
acoburn: ATTENTION: we will vote on w3c/
<gb> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
acoburn: in our Ghent F2F, we discussed a specification of containers. i hope we have a PR this month
… if we have a volunteer (from Ghent or a new volunteer), please let us know
TallTed: SoLID inherits from LDP
acoburn: it's unclear whether you can add user triples to a container, what it looks like in [framed] JSON-LD