Meeting minutes
Introductions & announcements
acoburn: any introductions?
acoburn: Lawrence isn't here today but I'll ask him to send to the WG mailing list info for hotels for the F2F which is in a little more than a month
Action items
[poll for unlisted actions]
Continued discussion of requirements ( #1 and #2 )
acoburn: over the last 2 months, we've looked at the draft requirements for the LWS spec
… currently have 39 candidate reqs, with 2 left to clarify
… goal: have an indication for the editors of what to focus on
… triage to important | nice-to-have | out-of-scope
… after we review the last two, we'll discuss the triage process
Use of Service Providers
hadrian: 2 Use of Service Providers could say "spec doesn't preclude service providers (e.g. for scalability)
acoburn: rename now?
hadrian: discuss now or should I take a stab at it for next week?
ACTION: hadrian to open PR to simplify and clarify the "Use of Storage Providers" requirement
<gb> Created action #34
hadrian: i'll create a PR with my pref phrasing and i'll include alternatives [in case others have a different pref]
[taking up 1. Globally Unique Identifiers]
Globally Unique Identifiers
acoburn: how much should we specifiy this?
… we could say:
… .. identifiers need to be URIs
<dmitriz> no it wouldn't :) DIDs are URLs
acoburn: .. identifiers need to be URLs (i.e. no e.g. DIDs)
<TallTed> requiring HTTP URIs would rule out DIDs
<dmitriz> unless you specifically mean 'https url'
<Zakim> gibsonf, you wanted to ask about talking about resources in a pod with uri from another pod
gibsonf1: can you reference a URI in POD2 from POD1
acoburn: do you meant the URI that serves as an ID or as a locator?
gibsonf1: e.g. ontologies: it's often helpful to re-define/enhance ontologies in your POD
… how would you reference with an ID that won't bring you to the referenced item
TallTed: not recommended to redefine someone else's ontology term
… you can derive, but then you'd mint a new URI
… the diff between a reference and the referenced item is important
gibsonf1: let's put away the ontology example and say you want to reference a friend
… you want to reference your description of them
TallTed: then you'd use a query service instead of following their ID
gibsonf1: would be nice to have that spec'd
TallTed: not sure what to spec but suggest an issue
ssuggest an issue/I suggest opening an issue/
acoburn: can i call this an "offset description" for supplementing an existing resource
ACTION: gibsonf1 to open a use case issue describing a mechanism to describe a resource that is located elsewhere
<gb> Created action #35
hadrian: do the identifiers we speak of denote entities or resources describing those entities
<dmitriz> I'm coming from a very particular place, when I say DIDs are URLs. to start with, WHATWG has long issued a statement that "URLs and URIs are the same thing."
hadrian: e.g. if a git repo (imperfect analogy, but...) is unique, we can refer to it regardless of its location
… (github, some gitlab...)
… this decouples us from the DNS
ericP: this issue arose a lot in bio2rdf because many groups wanted to redefine particular protiens/entities
<dmitriz> secondly, the 'did:key' example still supports the URL name. because, what's a URL? broadly, it's "you look at the protocol, before the first :, and perform the lookup according to its rules". And did:key has a very specific procedure that allows you to fetch the key. (instead of looking on the internet, it looks in the URL itself, but that's still locating.)
ericP: not solving that problem caused problems requiring a lot of string matching
Jackson: a month or two ago, we had a similar conversation. reiterating:...
… .. just saying that resources have IDs is insufficient. need to have a MUST on some standard identifier
<Zakim> TallTed, you wanted to note that "identity" is not usually definable by anyone other than the "identified" entity
acoburn: following your point, that makes writing a test suite more tractable
TallTed: UC&R usually don't include MUST/MAY (though SHALLs usually reflect as MUST in the spec)
… "identities" are human constructs
… what you deference that memory space, you get back a value.
… confusing because there's not typicaly a single value when you derference a URI but there is when you deref a memory location
pchampin: our charter rules new ID mechanisms out of scope
… when Jackson uttered "MUST" i believe he as refering to the spec
… re ericP's proliferation of IDs, I think it's more than a confusion between the entity and the description.
… it's "safer" to roll your own description
… a "locator" is anything for which we have a standard way to resolve
<TallTed> multiple identifiers for the same entity are not a problem. As long as they *are* the same entity, owl:sameAs is great. broaderThan, narrowerThan, etc. can help when they're not the *same* entity.
pchampin: I'd say that DOI URNs are names but current infrastructure makes them locators
hadrian: +1 to not inventing new ID scheme
… +1 to remembering use/mention distinction
<TallTed> I don't see anything in these use cases about divorcing from DNS
hadrian: but it's important to remember which IDs break when you lost control of a domain name
pchampin: re losing domain name, DID's are considered safer but people lose e.g. BitCoin IDs
<TallTed> DIDs are one option there. w3id.org is another pattern.
pchampin: every scheme has its vulnerability
… users will have to chose based on their use case. (we will make some choices for users)
hadrian: Q for pchampin: i understand that we don't want to lock ourselves into (any) scheme. is that true?
pchampin: brutal agreement
<pchampin> +1 TallTed
TallTed: at the same time we don't want to lock ourselves into a problematic but we can't design for the far future
… since we're designing for "Linked Web Storage", we can't throw out http(s)
Prioritization of requirements: How should we approach this?
acoburn: good discussion; we'll have more discussions as we design for solving the reqs
… next: i'll send a link to a Google Form to the WG list (not to the public) so we can rank reqs 1 (important) to 5 (unimportant)
… we'll discuss the ones upon which there is NOT consensus
… please fill the form out this week
… this form won't set anything in stone but helps us rank/prioritize
<TallTed> you can `i/nearby text/topic: blah blah`
bendm: does anything prevent one from marking everything with a 1?
acoburn: true, but if everything is equally imporatnt, we haven't sufficiently clarified the reqs
bendm: suggest limiting folks to e.g. five 1s
acoburn: good point. i'll add something
pchampin: i'd say that 5s are different, e.g. out-of-scope
… i suggest thinking in terms of absolute (required, out-of-scope)
TallTed: there are a lot of MVPs that don't interoperate
… dropbox, mbox, MS's thing... each intended to lock users into their tool
<pchampin> TallTed, agreed, "MVP" is not the best notion; the idea was really "minimal interop baseline" in my view
TallTed: we need to focus on the interop between 2 or more providers
… i can store stuff in Amazon as long as Amazon sells glacial storage for cheap, until my service runs up a big bill
… we need to target the enthusiast, allowing them to migrate to/from cloud services and their home server
acoburn: nice framing of the interop goals
[ADJOURNED]