<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.)