– DRAFT –
Linked Web Storage

Introductions and announcements

Introductions and announcements

pchampin: just back from TPAC. Nothing specifically related to LWS
… a lot related to VC and DID, sorry, nothing off the top of my head about LWS
… will sort notes and report back next week

Authentication proposal

Authentication proposal

<gb> Pull Request 43 LWS Authentication (by acoburn)

acoburn: at Ghent F2F, we discussed aaa at a high level
… last week, jeswr and I met to realize this vision
… should have a PR for this today or tomorrow
… will require more attention but wanted it in front of people ASAP
… please considier how it fits with authz

ericP: you plan to write an authz draft as well so we can see them together?

acoburn: yes, jeswr and i worked on both. will have authz in separate PR

Containment discussion

jeswr: (shares screen)
… topics raised in Ghent related to containment
… data in containers, semantics of data, container media type, paging for large containers

<jeswr> Data in containers

<jeswr> Is it server managed?

<jeswr> Can clients add data? or does client data go into metadata resources?

<jeswr> Semantics of data

<jeswr> Do we use LDP semantics?

<jeswr> What vocabularies? What terms do we define ourselves?

<jeswr> Container media type

<jeswr> RDF: JSON-LD and/or Turtle

<jeswr> Is Conneg required?

<jeswr> defined JSON-LD frame / JSON schema

<jeswr> to look up: can the response point to a json schema resource? (in json, link or well-known)

<jeswr> Paging for large containers

<jeswr> Mechanics

<jeswr> https://docs.google.com/document/d/1tHLQ2sylpP_J8JMlee4q3g-bx487qcgZ7Lbx6zIAzes/edit?usp=sharing

container discussion

jeswr: strawman proposal offers a JSON-LD container
… in a particular frame
… we would specify a schema for that frame, which would allow clients could treat that as pure json
… we would also define an LWS context so that the object could be interpreted as RDF
… first item is to discuss whether the JSON-LD is a MUST

pchampin: +1 to this proposal

<bengo> +1 JSON-LD be required. Is a particular *framing* required to be supported? (imho a good idea)

pchampin: have a question whether you are considering a particular media type or served as just json-ld

jeswr: acoburn and I had some conversations about this

<bengo> "application/ld+json; profile={uri}"

<bengo> is what activitypub does

jeswr: inclined to offer a custom content type, such as application/lws+json

bengo: I like the requirement of json/json-ld
… is there a particular framing required
… it would be a good idea for the server to use a particular framing

<Zakim> pchampin, you wanted to ask about media-type for containers and to

jeswr: that is my expectation: to have a particular frame

pchampin: I do consider two uses of JSON-LD
… one is generalized serialization (application/ld+json is best)
… another is defining specific formats which can be used as plain json or as RDF

<ericP> +1 to pchampin's discrimination of the use cases for JSON-LD

pchampin: for the second category a definite media type is appropriate
… as to bengo's proposal with a profile, there are some problems with that, esp with CORS
… not such a good choice from the web annotations spec

<bengo> I dont understand any CORS issues. haven't had any in ActivityPub using this to my knowledge

jeswr: is that an issue with the URL length?

pchampin: it's because the profile is a URI
… maybe we could add a keyword profile for json-ld, but I'm not sure if there is a mechanism for that

<bengo> AP 3.2 " The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type in order to retrieve the activity. "

<bengo> (conneg)

pchampin: another problem is content negotiation
… I would be nervous if there was a different profile using the same media type

bengo: unless one is very careful, the profile could drift to pure json-ld

<pchampin> bengo, Verifiable Credentials has some language that we could reuse

jeswr: I've seen issues in JS ecosystem with media type parsing

bengo: there are debates about the processing of custom media types

<Zakim> ericP, you wanted to say that no algorithms describe matching on profile. that said, maybe somebody has to go there first

ericP: no specs that describes how profiles are handled
… this could be a forcing function for defining profiles

jeswr: next topic: do we require content negotiation within the RS spec?
… personal opinion is that we should not require conneg (e.g., turtle), however, we provide a discovery mechanism for servers to advertise
… that they can transform to another format

<pchampin> +1 to keep conneg optional

<bengo> btw the definition or the profile parameter on application/ld+json is elaborated in here https://www.iana.org/assignments/media-types/application/ld+json

jeswr: are there other opinions on the requirement for conneg?

<pchampin> it could also be advertised with HTTP header "Vary: accept"

<bengo> I would like for the servers to not be required to serialize turtle, which I think is consistent with what jesse said.

jeswr: for JSON Schema, one option is to include a JSON-Schema in the representation
… are there other topics related to the framing

bengo: for JSON Schema, I don't know of any W3C specs that have normatively referenced JSON Schema

jeswr: I'm not a JSON schema expert so I'm not sure

bengo: from CR to TR in other specs, we had to drop features (such as JSON schema) that were not stable

<pchampin> https://www.w3.org/TR/vc-json-schema/

pchampin: normatively citing JSON Schema has been problematic in the past
… vc-json-schema normatively refers to JSON Schema

<bengo> (we had to drop 'json-ld signatures' but not json schema, but the rationale from the chair was that it was not a stable enough spec to normref. 5+ years later now we have https://w3c.github.io/vc-data-integrity/ )

<bengo> json-schema was never used in SocialWG

jeswr: next question on that front is how to reference the schema
… one option is to reference the schema in the spec
… another option is to include a link to the schema in the JSON document itself
… not sure if this is a standard approach, esp. with JSON-LD objects
… are there opinions on how to reference such schemas

pchampin: in reference to the schema key, there are several options: ignore or map the key to a particular URI
… we have examples of specs where a JSON-LD context and also provide a hash
… since the content on /ns is not normative

<bengo> I guess I have a question which is... is the json-schema going to be normative? is the JSON-LD frame context going to be normative (like in activitystreams)? what if they disagree or the schema languages are not equally expressive?

pchampin: we should also insist that implementations are not required to dereference the referenced schema
… we'll need to explain this better in the next version of the JSON-LD WG

jeswr: would be better to have some statement about this from the JSON-LD WG rather than define it ourselves

pchampin: JSON-LD is currently being rechartered
… the charter is already quite full

bengo: if both a frame and a schema are normatively referenced, what if they disagree?
… if they do disagree, there will be no deterministic algorithm

<pchampin> I agree that the schema and the frame serve different categories of users

bengo: I am more comfortable with a normative JSON-LD frame than normatively including a JSON Schema

<pchampin> and also that ensuring that both agree can be challenging

ericP: the benefit of making JSON devs happy shouldn't be understated

bengo: the schema doesn't help a server know how to serialize consistently
… JSON-LD frame will be more specific/deterministic

jeswr: can we derive a JSON schema from a JSON-LD frame?

bengo: activitystreams would benefit from that

bengo: we could dodge this by dropping json schema

pchampin: I would really like to have a way to derive one from the other

<bengo> My biggest concern is that json-schema does not help produce JSON-LD in a deterministic way, whereas a normative json-ld frame does.

pchampin: but I'm willing to standardize one and leave the other informative
… or specify both and state that if there is conflict, one takes priority

jeswr: this object we're talking about is not especially complex
… we should be able to normatively define the JSON-LD context

<ericP> +1

jeswr: and informatively include the JSON schema
… and be quite certain that they won't conflict

jeswr: next up: semantics of the data
… we need to define the data we want to describe and start defining a context
… which involves defining the terms
… strawman object of the kind of data to include
… go through each field
… first field "type: Container"
… assume this is not controversial
… the "totalItems: N" field, seems like optional
… for each child resource, "type: DataResource" seems like a required field

gibsonf1: related to paging, there have been attempts to define how many items in a response
… if we do paging, can we do this without intermediate items
… would like apps to be able to define the number of items in a page
… on containers, is it possible for the storage to contain containers but also perform a role as a container
… for example, if there are URIs that are not in a container you can still refer to them

<bengo> I dont like the 'MUST include exactly ONE type'

jeswr: i.e. you want to restrict what goes into a resource, I can only put data describing the subject of the URL

gibsonf1: I'd like to treat the storage as a named graph

jeswr: in Solid it was never a requirement that a subject must be in the resource where a subject is defined (i.e. at that url)

jeswr: suggest that we discuss named graphs for a future discussion
… related to types, are these the right types (DataResource, Container, MetadataResource)
… should we include the media type?

acoburn: for large containers with defined media type, you need to HEAD them all
… useful for things with a defined media type

<bengo> IMHO the notion of a resource having a single media type is confusing the nature of REST where a resource has many representations with many media types

<Zakim> bengo, you wanted to comment on mediaType

bengo: media type as a property is defined in activity streams and VC

<bengo> w3c/vc-data-model#1408

<gb> CLOSED Issue 1408 reconsider `@id` for `mediaType` term (by gobengo) [pr exists]

bengo: the bigger concern is that something with type: DataResource has a single media type
… Representations have media types, Resources do not have a single media type

<Zakim> gibsonf, you wanted to comment on container child type

gibsonf: related to media type, we deliver enough so that the app can display a list of items
… such as a type, which helps the app know what to do
… for a media type, there is a URI for that
… our implementation has an algorithm to know which type to display

jeswr: I want to extend on bengo's point about there being multiple representations of a resource
… would it be better to describe the "accepted" media types for a given resource?

<http: //www.w3.org/ns/iana/media-types/image/>

jeswr: for images, one may get a list of "image/jpeg" and "image/png"
… or define which media type was the one used when the resource was originally written

<pchampin> +1 to all jeswr is saying

jeswr: tbl has often opened issues related to the original form of the resource (e.g., to include comments from turtle document)

<ericP> ADJOURNED

<bengo> what I've been playing with, and sort of works well, is just reifying the representations. ie a resource is serialized as { representation: [{ mediaType: 'application/json' }, { mediaType: 'image/jpg' }] }

<bengo> jeswr fyi

<bengo> as opposed to { mediaTypes: [] }

<bengo> curious what you think. leaves room for future per-representation props

bengo: FYI, I'm very much in agreement with your concern about resource vs representation