Meeting minutes
<csarven> Ill. I'll follow up with UCs and other matter.
acoburn: are there introductions?
… are there annoucements?
acoburn: no introductions, no announcements
Use cases scoping and requirements
acoburn: a good number of use-cases have come in on GitHub
… scoping needs to happen
… let's discuss requirements gathering
ericP: discussing requirements shall inform scoping discussion
<ericP> Agent Identity - (unambiguously) store/exchange identities, e.g. URLs
<ericP> Fingerprint - resolve an agent identity against a real-world agent
<ericP> Authorization - grant specific access to agents
<ericP> Capability discovery - dynamically learn agent or site’s capabilities
<ericP> Data discovery - find data matching some criteria
<ericP> Data management -
<ericP> Lost Update - ensure that update 2 does not wipe out update 1
<ericP> Notification - (subscription) agent 2 notifies agent 1 about changes to data
<ericP> Portability - ability to move from one data provider to another
ericP: what can easily accomplished?
… (copied from GitHub)
… portability and identity are larger problems
hadrian: discussions do happen and not everything is reflected in the issues list
… there are interdependencies. solutions here may make our life easier there
ericP: there is no nice management solutions for the interdependency between portability and identity
… we just need to be aware
acoburn: is there anything missing from ericP's list?
hadrian: we should converge on the terminology that helps speed up things
kaefer3000: ericP is this a distillation from github or a copy?
ericP: this was a categorization of some issues, not comprehensive
acoburn: many use-cases are about authentication mechanisms
<ericP> +1 to keeping authentication separate from authorization and identity
laurens: +1 to that authentication is important
kaefer3000: I wouldn't expect the fingerprint requirement. What does this mean?
ericP: fits the role that in a lot of interfaces, somebody's icon pops up on @-mentions to give an idea who somebody is, like who do you write a check to?
<dmitriz> that's still authentication, yeah (the ssh fingerprint thing)
hadrian: non-repudiation and reputation should be out of scope but we should not preclude them with our work
kaefer3000: what is a UX problem, what isn't
ericP: proposal: let's have use-cases that are out of scope, reasons: 1) allow people to see that they have been heard 2) provides a test environment to us, for later layering those out-of-scope things on top
jeswr: does qpf or sparql fall under the data discovery category?
… where does security fall under?
acoburn: qpf= quadruple-pattern fragments, generalisation of triple-pattern fragments, querying technique
<acoburn> quad pattern fragments
acoburn: we need to distinguish between use-cases and requirements and solutions
jeswr: use-case: I do not want to trust my resource server, is that data management?
jeswr: two out-of-scope topics:
… 1) signature-based provenance, verifiable credentials
… 2) data governance, odrl. Important, but probably out of scope for lws.
hadrian: niko's use-case - structure for storage. is that data management? should we tackle it at all?
<gb> Issue 24 [UC] DECOUPLING between API PROTOCOL(s) and INTEROP specs (by niko-ng) [triage] [usecase] [needs-discussion]
acoburn: agrees that data governance and signature-based provenance should be out of scope, but they should not be precluded
dmitriz: we need sensible hooks for those points, but should not cover them
<pchampin> +1 dmitriz
dmitriz: we should add affordances for the future for things like auxiliary resources
jeswr: but we should not pre-assign specific solutions (e.g. odrl)
acoburn: to what extent can we just defer to HTTP?
ericP: I used HTTP/1.1 lingo when I wrote the points above
<Zakim> ericP, you wanted to remind folks that we'll want to allow some folks to predictably get some resources
ericP: regarding affordances without prescribing solutions: Linked Data Platform allows to, e.g. GET/POST resources, has test suite -- we want to control access to resources. If we talk about access control, we need a solution for identity, and this needs to be reflected in the test suite
… in contrast, ODRL has rules for what things need to look like but has no test suite.
… thus, in that sense, LDP may be the better role model than ODRL
acoburn: next meeting on Jan 6