<ericP> shex to generate HTML forms
<dmitriz> ericP: I have a question about Shex
<dmitriz> shexJ specifically
<timbl> "next call 2019-03-21(?) 2pm(?) CET -- call-in details & agenda TBA" ?
Mitzi to ericP: what do you need from the group? decision? proposed spec change?
ericP: let's brainstorm, want the
group to be aware of it, and how you can use it
... Ruben will probably have more answers as well
<Oshani> timbl, https://zoom.us/j/121552099
dmitriz: question: really excited to see that shex has a json-ld serialization
do you know, could you map between shexj and json-schema
ericP: limited, json-schema is more like a list of properties, you can kind of coerce it to have a closed content model, but it would be awkward
justin: the community need
solutions likes shex
... ericP has been pretty active, collaborating with us on it.
it's some really good work that people should look at and see
if they want to use it
ericP: for instance having two addresses ends up being awkward in shacl, so shex could be useful there
shex model is simpler than shacl there
much easie rto write schemas
shacl doesn't understand a choice between something that is a conjunction (given name, family name)
Mitzi: asks if there are any final comments about this
ericP: shex evaluates all expressions in context. the extends model that they are working on right now, ... data is reusable, schemas are reusable, one schema could extend another and add extra properties to it
it's hard to see how you could do that in shacl
justin: that's actually one of the things that got me pretty excited about shex
the idea that you can have a base shape that you can extend is exciting for collaboration
<ericP> acl mext
timbl: in that case, i woudl just point out that yes, shacl is linked data, so you can link shapes together
you can have extension shapes, merge, refer to it..
you can invoke another shape kjust by using its url
becausee it's linked data, that makes it easier to work with
ericP: there is an rdf representation
all implementations of shex work with turtle as well
they conbsume shexj, shexc and shexr interchangable, there are 600 tests to make sure of that
what you can;t do with shacl is systolic/diatolic
bloodpressure with a code of one of those
to extend that, with e.g. postures, the extension mechanism of shacl would not allow that
then you get in complex situations
with restrictions it's possible, but extensions are impossible with shacl, so thta's where shex excels
Mitzi: next topic, Ruben?
RubenVerborgh: i'll try to give a brief overview
about shapes
shapes can be the new ontologies, a major driver for solid
apps will indicate with a shape on which kind of data they want to operate
the core thing about solid is about interoperability
examples: many differnet ways to organize your pods in folders
e.g. one 'photos' folder
or by event
or by project
apps nbeed to understand where they can find and write photos
of course, because it's linked data, the finding part can be solved by just following links
but what kind of links do you need to follow? on my pod for instance, photos are in subfolders of projects
shapes can be reusable
and they are going to be composable
for instance photo album has title, name, events, etc.
even if my pod is different from yours, i can refer to a photo album
and apps can understand the photo album shape regardless of pod folder structure
also: permissions
so which of the locations that habve a specific kind of shapes do you want the app to be able to access
if you data is on a slightly different shape than what the app expects, we can have tools that transform it a bit
that is another role i see for shapes
interested to hear feedback about this
<Zakim> ericP, you wanted to say that with shapes, the LOD cloud could be computed
ericP: (hard to hear)
... ok, so the linked data cloud could be arrived at statically
by looking at shapes
ability to sort of derive that
having schemas of some sort, habving shapes, allows us to mabnage those interconnections
Tim: i wanted to scale back, the things that Ruben cites are funnily exciting
but down the line, on the other hand
alert queries in dynamic ways
we are defining shapes for...
the way the solid project uses shapes
is toh have standard solid shapes
please use and agree on a shape for each thing
don't just make arbitrary shapes out there
we can use shapes for different things, but it is a new world
exciting and powerful but the first thing we want from solid is interop
everybody use the same shapes please
footprint for write, shapes for read
<ericP> +1 to timbl's "don't invent a million shapes" message.
i validate my contacts every now and again
<ericP> ontology/schema reuse is hard; it's also the only way to get interop
<Mitzi> (michiel) data browser is a good starting point
Ruben: the need that i see on the long term
it makes sense to think about that,
alreadty using small versions of shapes
the stuff happening now on the front end shows a need for shapes. this is a good first step,
we might need shapes earlier than we expect
in the mid-term
Mitzi: any more comments?
Tim: rdf forms are very much like shapes
whether you use vcard:name or foaf:name
if we are going to use schema.org for example
there is a simple case where the predicate you are using is the legacy one
and a shape on the form
this is a property for this field, but hte legacy property is that
so extending the shape language a b it to allow for legacy properties, very easy to add to a form when reading, but always saving in the latest one, your data gets cleaned up
Ruben: as an example Tim used a different vocab for Likes than i did
schema.org is an option
what are we going to use?
Tim: they would like us to adopt a policy of always using shcema.org
partially a philosophical discussion, the one true namespace
dmitriz: community discussion, where should we put thos definitions?
Tim: shapes are like ontologies, you should get a piece of w3.org so that they will be there forever
one problem with that at th emoment is you can only access that with cvs (?)
we could use git instead
as thjey get more finalized, the url's shouldn't change
dmitriz: should we do this in the https://github.com/solid/vocab repo?
RubenVerborgh: people should start creating proposals
taking from what already exists
Mitzi: i'm concious of the time
justin, final point about shapes: mentoin the same thin gt hat RUben just did
we have some time slotted of with the folks in Boston, getting together tomorrow to do some concepting on the experience for that
how people who are creating shapes are able to collaborate on that and publish themn in a way also as a vehicle to discover them
you need a mechanism like shapes to facilitate interop, but also a way for people to find them, so we need to chat about that
dmitriz: DID in the solid spec
just to start the conversation, we can continue it on the mailing list after this
there is a bunch of work being done in w3c groups now on 1) decentralized identifiers and 2) verifiable credentials
we had a demo yesterday by Kayode of his implementations of VC on top of solid (https://github.com/kezike/solid-vc)
and what steps can we take to interact with the DID spec
blockchain-based or distributed-ledger based, or https-based DID method
the latter seems tailor made for Solid
let's talk about interop between DID and webid
(me:) what would the difference be between a https-did and a webid?
<timbl> Does it give uou an http: URI for the person ?
dmitriz: it has aslightly different schema
Mitzi: what would b epractical steps now?
<dmitriz> timbl: it does (give an https: url for a person).
dmitriz: thread on the mailing list, or pull request on the DID repo or spec repo
<dmitriz> or a group, or an agent
timbl: if you have a pod with a http url
DID can tell the system where your pod is
dmitriz: absolutely
it's only dealing with https, not http, but asside freom that there is a one-to-one mapping
we need to settle on a triple in the profile
from webid to DID and from DID to webid
justinwb: tyou mention where it's compatible. first of all, i support that
but where would it be fundamentally incompatible? if any?
dmitriz: i don't see any such spots
we would need to add support for did to for example rdflib
and same on the DID side
but no philosophical incompatibilities
so let's say we go to the complete extreme, and decide we want to use DIDs now
what would that migration look like?
dmitriz: the migration script to generate a DID doc from a webid profile, might be generate a couple more keypairs, but other than that trivial
justinwb: ok, so then what would the middle ground look elike, living in both worlds
you may have a case where oyu sometimes use one and sometimes the other
dmitriz: yes but we would lean ont he discovery process
so you can discover the DID when logged in with webid, and v.v.
Mitzi: next point is "the default"
one of the criticisms of solid is tha twe rely on consent, and certain tihings should never be possible
i'm interested in both the minimum amount of data you share, but also in a maximum
not to get ahead of those questions,
area there any objections to starting a new repo
to go through the points where the default would be relevant
and go through the details of that for those
Tim: who has written the book?
Mitzi: can't pronounce her name, but she's Turkish
TIm: she has proposed ..
she's looking to build a world with very minimum sharing
in solid you're able to share always with particular people you care about
if she describes a way for us to go, i'd like to see it defined more clearly
Mitzi: yes, i've reached out to her to see if we can come to some sort of practical solution to this critique, and build an answer
any objections to starting this?
(none_)
ok, wonderful! i'll let you know which steps i take
we really have quite full agenda's
perhaps we need to swith to weekly
<dmitriz> +1 to weekly
(me:) weekly works differntly than monthly, the group will be smaller and more involved
Mitzi: what if we alternate between weeks where we talk about spec aond ones where we talk about other topics
justin: but we could also just go three weeks in a row on a specific topic
we need a fair system for prioritizing backlog
(me:) let's expand the agenda in the weekly announcement, then people can decide whether they show up or skip
Mitzi: solid world is a (moderate) success
dmitriz and i have been talking about doing a podcast
a 20 minute recording about some of these discussions
of course, the proof is in the pudding
any thoughts about creating solid world podcasts?
<justinwb> +1 to podcast
objectiosn, commenbts?
final chance...
we've reacht the end of our time
rest of items will roll over to next week agenda
any final comments?
ok, see you next week!
RubenVerborgh: you know how to tell Zakim or RRSAgent to draft notes?
ericP: do you know?
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) Succeeded: s/shales/shapes/ Succeeded: s/cdf's/cvs/ Present: pano_ WARNING: Fewer than 3 people found for Present list! No ScribeNick specified. Guessing ScribeNick: michielbdejong Inferring Scribes: michielbdejong WARNING: No "Topic:" lines found. 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: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]