<michielbdejong> https://www.w3.org/community/solid/wiki/index.php?title=Meetings&oldid=295#instructions
/invite rrsagent #solid
<scribe> scribe: nicolasS
michielbdejong: We could
introduce the databrowser as a machine-readable homepage
... since the databrowser is the main user-facing component of
solid, this gives a good idea of what can be expected of the
solid experience
csarven: Clarification around
databrowser (DB) and homepage. DB is an app, and the homepage
is a resource containing linked data, but the two are not
necessarily entierly coupled.
...: If the homepage embeds data as rdfa, the databrowser does
not necessarily access that. Ongoing discussion in issue 69 of
the spec.
<elf-pavlik> elf-pavlik: data browser doesn't seem covered by any of the drafts and i see it more as custom feature of NSS
I'm sorry elf-pavlik I missed the beginning of your point
great thanks
<elf-pavlik> csarven: NSS allows serving data browser on text/html requests to rdf sources
<elf-pavlik> ...: NSS has it enabled by default and one can disable it with config or cli flag
KjetilK: TBL vision is that the
DB could bring back the homepage as in the old days of the Web,
where you introduce yourself
...: but with the DB you can go beyond, having access control
and machine-readable data. It's a base app implementing a set
of functionalities that are a useful to any Web user
csarven: The DB is an application that would load the homepage resource, find the triples in it, and expose services on top of that
elf-pavlik: The DB and the homepages should still be separate entities, with the DB having a one-size-fits-all approach, while the homepage is something that is bound to be very customizable
csarven: the DB is not an essential element of Solid as in one may have a Pod and Solid apps without using the DB. The DB is not part of the spec either, so its usage is more implementation-specific than anything else
elf-pavlik: Question around the HTML that is generated by the DB, and how using it in a client-side HTML editor
<elf-pavlik> elf-pavlik: if someone uses html editor app, this editor may need a way to detect DB generated html which is not intended to be edited as HTML
elf-pavlik: The DB should be able to edit the user data, but it's not going to be able to edit consistently the representation that the user chose
<elf-pavlik> https://github.com/solid/specification/issues/69
csarven: The databrowser is an application that consumes the data in the homepage resource (and data hosted in any other resources), but it's not meant to edit the HTML representation of the homepage, at least in its current version
michielbdejong: This discussion ties back to https://github.com/solid/specification/issues/69, the index.html discussion
csarven: The DB piggybacks on the HTML to load JS and data, and is more in a data consumer position, as opposed to dokieli for instance which has a more active role in the resource that it exposes
<Zakim> elf-pavlik, you wanted to discuss intent to write spec for data browser implementations
elf-pavlik: What should be the features of the current DB that could be moved into a spec generalizing the Data Browser role as a component of the Solid ecosystem
KjetilK: The DB is orthogonal to
the server
...: It's "just another app", even if it is a component that is
exposed to everyone in the current Pod hosters
... Therefore, it's not necessarily required that its behaviour
is specified further.
MikeAdams: Should the DB be able to write data to a Pod ?
<elf-pavlik> https://portal.inrupt.net/
<elf-pavlik> nicolasS: inrupt.net exposes data browser as default app, i know of some discussions about customization to produced html but i don't think anything implemented yet
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: csarven, KjetilK, nicolasS, michielbdejong, elf-pavlik Present: csarven KjetilK nicolasS michielbdejong elf-pavlik Found Scribe: nicolasS Inferring ScribeNick: nicolasS WARNING: No "Topic:" lines found. WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]