<roba> looks like i'm the only person on webex?
<roba> * or is it a new link today?
<roba> * Pwinstanley aye
<AndreaPerego> s/sscribenick: PWinstanley//
LarsG: Nick has done a lot of work looking at content negotiation using querystring arguments in URLs and in defining an abstract API through which clients and servers can describe their potential resources either through full URLs or through tokens
… I am keeping up with that, and I should be able to commit something today on content negotiation by profile using HTTP, and this, following review of the group, should be adequate for FPWD
… the next meeting should be able to review and publish
antoine: next week is too early for a vote, but perhaps is a good chance for awareness raising
kcoyle: on 30th Oct we can introduce the draft, and then propose the vote on publication on 6 Nov
LarsG: asking roba if it suits
roba: there is a bit of work to be done, but it is only writing - not much in the way of examples etc.
kcoyle: can this be done by 30 Oct?
LarsG: yes, it can be finalised by then. People will have a stable doc to review
antoine: re: managing expectations - has Ruben had time to look at this?
LarsG: I keep sending him information, that is the best I can do
kcoyle: what is the interaction with IETF work?
LarsG: the IETF draft is a request for registration of 2 new HTTP headers: Accept-Profile and Content-Profile
… then we will have the calling by AP doc giving information on how that fits in with the content negotiation by profile model
kcoyle: timeline dependencies?
LarsG: we need IETF comment before we go to CR
antoine: content and scope, whilst basically about querystring arguments (QSA) , how comfortable are we that this matches the charter focus on HTTP
<Makx> alejandra I am looking at it. what do you want me to do?
roba: QSA - using a paramaterised URL reflects current practice. Profile negotiation isn't supported by headers, so people just invent their own ways. Giving a conceptual model allows people to see that the headers will do the process that is currently done other ways. We are making the http
headers proposals relevant using terms of approaches that people really use. So do we use an abstract model, or do we describe / explain using a canonical model.
<Zakim> DaveBrowning, you wanted to ask about fall back work
DaveBrowning: just for clarification, I thought we had a charter requirement to provide a fallback in case IETF didin't move in our direction
LarsG: yes we do. QSA is a fallback mechanism. If we don't get the IETF review then there is an alternative.
JerermyTandy: look at the WoT group to see how they are tracking JSON/LD
<Zakim> LarsG, you wanted to talk about charter
AndreaPerego: I am concerned about QSA - is it appropriate for standardised querey parameters, what if they are already specified for other purposes?
… supporting http headers is a way to overcome the issue of catalogue services that use these parameters, but using QSA, I'm not sure as to how that could work
antoine: there are standard API like OpenSearch that do this, are we in a similar position to them where we can standardise the way they did? I am keen on having QSA somewhere. My doubt is the strength of the recommendation, especially when looking at the abstract model. It would be a pity to
get negative comment which might push us to remove the abstract model - we need to save that
... I think this should be in the same doc, but non normative
<antoine> +1 for roba on strongly encouraging a mapping between the model and whatever API people use
roba: I agree with the 2 points made. QSA is in use; and we need to be able to describe what people actually currently do. We could provide a mapping of the paramaters that people should use. We could extend the profile description ontology to show the mapping between an abstract parameter and a
real one. I think it will be simple to deliver a solution once we understand what the recommendation will be
LarsG: seconding what roba just said. The mapping from the abstract model to the proposal is still work in progress. We can provide a recommendation on how to document this, together with illustrations.
AndreaPerego: in this case the parameters for mediaType could be flexible, I think the normative requirement is too much
LarsG: I agree with you, we haven't fully considered it
kcoyle: will you add something into the draft to soften this requirement
Action: LarsG to add note about QSA to the conneg document
<trackbot> Created ACTION-249 - Add note about qsa to the conneg document [on Lars G. Svensson - due 2018-11-02].
kcoyle: any other things to say about conneg?
… othr dependencies between conneg and the other 3 deliverables?
roba: there is one around the description of where a profile is a sub-profile and conneg. we need to be able to let the client know about both more specialised profile and the 'parent' more generalised profile
kcoyle: this is tricky, bringing uup the discussion on what it means to say something is a profile of something else. From the LoV statistics, almost every vocab uses some DC. if you ask for DC you might get every vocab. So we have to watch when we say that something is a profile of something
AndreaPerego: agree, esp when dealing with e.g. media types. If I am looking for geoDCAT-AP and I get DC, is this acceptable to the client? it is safer with mediatype because there is defined structure that provides the relations, but in other situations it is dangerous
riccardoAlbertoni: I agree it is dangerous.
<roba> I dont haver a strong opinion about solution - but now we have moving forward I am willing to think about it some more :-)
kcoyle: other comments? yesterday it was stated that our goal is minimum interdependencies, so we need to look if we *have* to have them or can we do wihtout them
<riccardoAlbertoni> I am also saying that to limit the dangerousness we should think to distinguishing different kinds of profileOf relationship..
LarsG: the IETF document would cover situations of requests for profiles that don't exist
<roba> i think the response is easy - its the listing thats trickier perhaps
kcoyle: the dependency with profileOf is with the default. Is it necessary to be that specific, or can we have a default within a family of documents
roba: we should follow the logic behind conneg by format. it is up to the client to specify what it is looking for, not the server
… I think the response neg is straightforward. The mechanism for advertising what is available is trickier
<Zakim> LarsG, you wanted to talk about q-values
LarsG: The client has the option of using q values in the header. But do we put the burden on the client to know what is available, or do we get the server to provide a return with other options that the client might have asked for
… this is a challenging question when we bring in profile subsumption
<roba> if profiles are identified by derferenceable URIs (with profiles ont canonical views) clients can access all information - perhaps its up to deployers to decide which to list (as a cache of the linked network resources)
AndreaPerego: there is no governance in this , it will be tricky to know how a server might implement this. I would support the main burden being on the client. The client knows the recipient system
kcoyle: will the IETF doc reference the proposed conneg doc?
LarsG: yes, as an illustration
roba: +1 to AndreaPerego. The server is able to provide some info, but the main burden is on the client. The client can use URIs and RDF to work out via network traversal what options are available. Servers should have the ability, but clients should have the responsibility to discover what is
antoine: this is a way to motivate getting a profile description
Action: antoine to add a note to the profiles guidance doc to indicate the motivation to have desrciptions of profiles is to help clients find out what is available
<trackbot> Created ACTION-250 - Add a note to a profiles guidance doc to indicate the motivation to have descriptions of profiles is to help clients find out what is available [on Antoine Isaac - due 2018-11-02].
antoine: what do we do about editorial stuff for this conneg doc?
LarsG: wait till I've got my comments into the doc
DaveBrowning: motivation - are you thinking about adding motivational statements, reasons for why we did what we did?
antoine: might be both.
… we need to say we identified gaps, the profile ontology was needed to fill the gap, etc etc
DaveBrowning: from TAG comments this is seen as providing clarity of motive
kcoyle: one thing relating - I have bookmarked a description of gaps. What does exist and then what is missing.
… I also volunteered to go through and check that we use USA spelling. Do I wait to the end? It needs to be done before we go to FPWD
… we can figure this out together LarsG before we send to W3C
alejandra: Have we planned implementations?
LarsG: Nick is working on one in CSIRO. We will try to make an implementation of HTTP headers
AndreaPerego: I am going to try an implementation for GeoDCAT-AP
… it will implement conneg for mediatype, and I will extend it
LarsG: what is an implementation? Is a PoC enough?
AndreaPerego: this will be on the web, so it will be in production.
<roba> I expect to implement at OGC Definitions Server
antoineL the social web rushed something through from Europeana
<AndreaPerego> GeoDCAT-AP API here (including link to online demo): https://github.com/SEMICeu/iso-19139-to-dcat-ap/tree/master/api
kcoyle: assume that prototypes are implementations unless told otherwise
<roba> and I beleive Nick is poised to implement an Australian government deployment
roba: for conneg and profiles, the motivation for nick and I being in the group is that we are actively working on systems that will use what we are describing, so this will provide working systems
<AndreaPerego> The OAI-PMH equivalent to the GeoDCAT-AP API: https://github.com/ec-jrc/datacite-to-dcat-ap/tree/master/api
<roba> a dcat profile for cataloguing profiles makes sense :-)
kcoyle: do we want to catch danbri to see if we can discuss discovery using the profile ontology - so we want to see what can be done to enhance search options? Also, can we see profiles as datasets and use Google's understanding of DCAT to then use DCAT for topic to help discovery. How will
people find profiles? Will what we are doing aid that
<Zakim> brinkwoman, you wanted to let Jeremy say something
<roba> * cant quite hear
brinkwoman: Jeremy here. I was talking to danbri. his suggestion is to use site maps to attach resources to the home page. you can stick all kinds of stuff in a site map, it is a well-known place for sticking stuff
<roba> cool - we should add an issue to profile guidance - and an example in profiles ontology of a site map advertising profiles
brinkwoman: conneg for profiles was probably less of an interest because it is asking people to run before they can walk
roba: all kinds of stuff - does that mean descriptions from the profiles ontology too?
brinkwoman: Jerremy: talk to danbri for clarification
<Zakim> antoine, you wanted to talk about https://iiif.io/api/presentation/3.0/
<roba> so its one possible mechanism to list supported profiles (by domain of server)
antoine: IIIF link has an API to publish images, but the service for images also has metadata and in that there are links to more complete descriptions of the objects. That is done within the manifest.
… in the manifest there is a seeAlso that points to other attributes including profile locations
AndreaPerego: in this case the profile is what?
antoine: it is the profile for a bibliographic record, but there are also profiles for image delivery services
… we have tested stuff with site maps at europeana where we have tried different ways of harvesting metadata. There will be an example that I can find
<roba> * I'll be back fo rthe JSON-LD session
<AndreaPerego> [coffee - back in 30 mins - 10:30AM CEST]
kcoyle: are there any other dependencies that we need to deal with?
… there is the section on 'family of documents'
DaveBrowning: what is the criterion for being in the 'family of documents'? The profiles work is more general than DCAT, so it could be decoupled
… alternatively, it could be one of a broad set of documents to do with data exchange
antoine: on that same point there is discussion in github, by putting DCAT next to the profiles we might be suggesting a relation that doesn't really exist
DaveBrowning: The other way round, there is an open quesiton about profiles of DCAT. Perhaps we should do a profile of the new vocab that defines the 2014 version
kcoyle: That is out of scope of the charter but only for specific narrow domains
DaveBrowning: It would help DCAT1 people migrate / crosswalk
… it might be an interesting validation exercise
kcoyle: it can be done and mentioned off the wiki page
DaveBrowning: I can collect it as a github issue and we can revisit later
kcoyle: all the documents from this group - the wiki page will remain. we can either get rid of extras or else follow DWBP and create a page for their deliverables
… that is where we will list all that the group creates, both informative and normative
… What do people recommend for the 'family of documents'?
… how do we do this coherently ?
antoine: I a keen to keep the bullet list for the 3 profile docs for each of the 3 docs
… but treat DCAT as a separate doc. It is too difficult to spend ages describing the (distant) relation
AndreaPerego: agree with antoine, there can be a link from DCAT but in the profiles it doesn't make sense
<alejandra> +1 to antoine and AndreaPerego's comments on the family of documents
antoine: even using dcat elements, there isn't point in adding it to these bullet points
proposed: that the group of profile documents should appear in each of those profile-related documents, but in dcat only mentioned in a section of profiles
proposed: that the group of profile documents should appear in each of those profile-related documents, but in dcat only mentioned in a section on profiles
proposed: that the group of profile documents should appear in each of those profile-related documents, but in dcat we remove that section
<kcoyle> proposed: only the group of profile documents should appear in each of the profile-related documents; the DCAT document will remove the family of documents section
Resolved: only the group of profile documents should appear in each of the profile-related documents; the DCAT document will remove the family of documents section
Jaroslav_Pullmann: there are assertions where terms from other vocabs are used in DCAT, e.g. DC
kcoyle: but we are talking about interdependencies between documents
Jaroslav_Pullmann: there are examples, I think we should use referential examples that are interlinked
DaveBrowning: I agree with AndreaPerego that it is difficult to be generic, and trying to cultivate a style with reuse might be OK but we shouldn't make them too solidly linked. We should focus on the kernel of the illustration. There is a risk of dependencies falling over if we over-rationalise
kcoyle: Is DCAT planning on more examples
<riccardoAlbertoni> +1 to DaveBrowning's comment
kcoyle: so apart from conneg-IETF, and profile guidance & ontology there are not many other links
kcoyle: the last link of resource roles
alejandra: is it worth distinguishing between the ones that are processes (e.g. validation) and those that are vocabulary and without action (e.g. with Prov)
kcoyle: we just had things, we didn't have any processes
AndreaPerego: looking at the profile ontology, the roles need clarification. the role is intrinsic to the role descriptor.
<alejandra> for processes, we will need to link to associated methods/scripts
AndreaPerego: if I have to validate data, is the validation role that is requires a ternary relationship to be expressed
… we need to think about this part before deciding where resource role should be placed
antoine: we need to have the discussion on aligning the models first
AndreaPerego: I see a sense in that I have a resource to be validated and the validation is done using one resource descriptor, and other functions using other resource descriptors
kcoyle: could this be related to an issue discussed in profiles guidance where entities can have >1 role
… e.g. defining constraints as well as documentation
AndreaPerego: I can use e.g. shacl graph for validating, but only on (class of) thing
antoine: the role is a potential, and there can be several. and this can be jeopardised by a file containing several profiles
… there could be a profile that is validating in one context and a guide to input in another
<kcoyle> scribing Peter - brings to mind TeXtile, documentation + R code gets converted to document that is a rendering of the documentation
alejandra: this is related to linking the profile to the artefact that allows checking, such as the shacl. it is worth having these roles not just as annotations. they should link to actionable stuff
… this could relate to the literate programming example
s/rendering of the documentation/rendering of the documentation and the execution of the code/
AndreaPerego: need to review the conceptual model for this part a little more to be sure we are going in the right direction
Jaroslav_Pullmann: relating to the machine processing, my hope was to find e.g. automated testing as part of the build processing, but we don't have this motivation.
… the benefit I'd expect from such as desription of a profile would be to facilitate automated testing
… going to machine readable gives us some scope for supporting automated validation. alejandra mentioned that functions should support a method to link to a resource that supports validation
kcoyle: I am concerned abot exploding complexity if we go for supporting automation
… the ontology was originally for describing profiles and related resources. In the roles there is conformance test, so it does drift into the automation of functions. We should look at description first, but only move cautiously into automation
antoine: I think at the moment profile ontology is purely in the realm of description. I don't think we are moving to semantic overcommittment
… when something is represented as a skos Concept it has a very low ambition, and that to me is reassuring
alejandra: this clarifies my point. A role associate with a shacl doc indicates what is required for validation
antoine: I think that could be linked to the resource
AndreaPerego: you have to say for validating what ....
antoine: for the moment that pattern is OK so long as there is only one link between the profile and the descriptor. The diagram in the document shows only the simplest case.
… I think at this point cardinality issues are best left aside
kcoyle: I find the diagram confusing in that the validation isn't happening on the profile, but on instance data to see if it conforms to the profile. We are describing rules for the profile, there is no data to act on
… I feel that some of this diagram drifts into application scope
… what is the relation between validation and the profile. the validation is on instance data that might conform to the requirements of the profile
LarsG: You can also have a profile that validates other profiles
AndreaPerego: The roles here , do they really need to be in the ontology, or can we do without it
Jaroslav_Pullmann: the role could be localised to a particular distribution. this relates to discussions we have had about dstributions conformant to a profile - the resource role could be a complex relation linking specific distribution to profile with a specific function. I'm missing something
kcoyle: so are you asking how do you connect instance data to a profile. is it an n-ary relation ?
AndreaPerego: This would make the diagram more complex
antoine: and I'm not sure, perhaps we need a more specialised profile
antoine: can Jaroslav_Pullmann please send specific examples
… then we can see how they are represented with the model. we need concrete examples
… I think we can do without roles, but I don't think it having them in the work is an impediment, we can give it a try
<roba> i'm back ...
<roba> can I ask for a quick summary
kcoyle: i can think of use cases for the roles, e.g. ways in shacl to include labels, descriptions or comments
… I can imagine wanting to have certain components (display, forms, etc) and get those, but you don't know the location. If you just want to validate then roles can be skipped
… we have yet to define the baseline profile.
<roba> just constraints, specified any way
kcoyle: there might be something totally minimal, yet functional
Questions for Danbri
kcoyle: discoverability - Jeremy said stuff about sitemaps. We have an idea of how through DCAT datasets can be discoverable. We need to know how best to resolve profile discoverability. Jeremy thought that sitemaps might help. What do you think?
danbri: I have no idea about profiles, because I'm not exactly sure what is needed for discoverability even though I know what it involved in a profile
… how many do you expect there to be?
roba: there area 2 things: discoverability of profiles (moot point if that it the purpose of search engines)
… and datasets
… when implementing one decides the dimensions of the data, and a profile provides that information which tends not to be present in DCAT. The profile and profiles ontology allows one to make a declaration about the semantics a dataset conforms to
danbri: schema.org and google datasets has raised the issue of discovery vs deep introspection of data
<roba> classes of dataset - exactly (and millions of these!)
<roba> - yes - its able to specify IPED conformance
danbri: the notion of profile is at the level of data description. e.g. USA IPEDS (schools info) .... would be helpful to look across all IPEDS datasets
<roba> and provide pointers to various ways a profile may be further defined
<danbri> example would be a property/value pair attached to all IPED datasets like https://nces.ed.gov/ipeds/use-the-data
Makx: I had a discussion about this subject. Don't leave it to the user, but get the producer to indicate the profile used in production. In ADMS supportedSchema gives this information.
<roba> max - conformsTo does this (schema is a very narrow interpretation of possible constraints)
Makx: this property could be in the description of each dataset. It gives an indication of the profile on which the data had been produced.
<danbri> alejandra might remember https://github.com/schemaorg/schemaorg/issues/1516 "Allow Dataset to indicate "according to specification URL"
<AndreaPerego> roba, dct:conformsTo is actually the property Makx was referring to.
kcoyle: Makx comment is exactly the same as comments that came up earlier - connecting instance data to the profile
… the important part is the instance data, where is it?
AndreaPerego: what are we talking about? do I just want to find a profile to work on/with?
<Makx> Yes Andrea, that would also be possible, but on the CatalogRecord. dct:conformsTo on Dataset referes+
AndreaPerego: or do I want to find data conforming to a specific profile?
<Makx> refers to the standard the *data* was produced against
<alejandra> actually, for datasets in DATS we included the conformance to a profile at the distribution level: https://github.com/datatagsuite/schema/blob/d79bd4ba9867832b2556495cd75dd05a2d3c99a0/dataset_distribution_schema.json#L87
kcoyle: there is a use case for discoverability but we haven't talkined about ti in detail
<Zakim> danbri, you wanted to discuss schema.org #1516, could we add a simple common property in both schema & dcat, "datasetProfile" that does this?
danbri: the last link is the discussion at schema.org, concerning conformsTo and its applicability to this case.
roba: we need to talk about the datasets conforming to profiles. dereferencing and cataloguing these profiles is a given, and uninteresting
… the challenge is when data is accessed by services that can use profiles. This is mainly looking at what the data conforms to.
<danbri> "A basis for comparison; a reference point against which other things can be evaluated."
roba: The profile specialises other standards and applies other constraints to let users know about dataset conformance
… do you declare all parent profiles? The profiles ontology allows dereferencing and the result is all the parent profiles
… in one jump the client can find out all that the data conforms to.
… it is powerful enough to handle all that we have discussed. the main question is packaging
<danbri> for funding, https://github.com/schemaorg/schemaorg/issues/383 ... we got close to a design, close to what DOI datacite folk have
alejandra: in DCAT we have Resource conformsTo that refers to a DC standard that the profiles extend. Is this enough, or do we need more
… this is for the dataset
danbri: in schema we would need to add conformsTo to createdwork
Makx: I think there are 2 levels. conformsTo relating to data
… the discussion yesterday was the profile the description conforms to
<roba> yes - descriptions are data and also wil have profiles
<roba> this is a good point - and its up to DCAT to work out how to self-describe profiles if necessary
roba: there is a requirement for DCAT profiles to be used,
… it is an open question of whether the description of the specific DCAT is described
… what property would be used ? using conformsTo in DCAT relates to dataset, not to the metadata
<Zakim> danbri, you wanted to mention funder/organization/project additions, e.g. "search within horizon-2020 funded projects" or "all projects funded by NIH"
danbri: I want to mention explicitly the funder, grant etc issue
… in schema we have this issue.
… is there a similar set in DCAT?
<alejandra> we have this open issue about funding: https://github.com/w3c/dxwg/issues/66
DaveBrowning: There is a clear need to support this in some way, but should it be in DCAT or coming in from the profile
roba: this is a topic I'm familiar with
… in the GEOS area
… people tend to use the project as a surrogate
alejandra: is roba point about data and metadata not covered with conformsTo in dataset and in distribution?
roba: I don't think so. we could make it the case but the ise of the the same term for different purposes is messy
antoine: I want to return to IIIF,
… there is a mechanism to state that metadata conforms to a specific profile.
<phila_> -Description of a Project (DOAP)
antoine: in the manifest there is a mecehanism for showing that metadata conforms to a specific profile. If DCAT and Schema are going to be using conformsTo then perhaps IIIF should be asked to come into line
BACK AT 13:30 to meet with JSON/LD group
<phila_> Worth saying that DOAP is actively managed by, among others, Kjetil Kjernsmo, formerly of this parish
<roba> we dont have dependencies on doap yet, so this seems quite a leap, given the semantics of dct:conformsTo is adequate (unless we have a counter example?)
<roba> so questions: is a frame a special case of profile that constrains a schema, and a json context the "import closure recipe" for a frame?
<roba> is this the same as a "shape"
kcoyle: meeting being handed over to azaroth to tell about JSON/LD wg
azaroth: whe requesting JSON/LD it would be useful to have a profile to define what is being requested
<azaroth> link: https://github.com/w3c/dxwg/issues/261
azaroth: in JSON/LD there is mediatype . params have to be defined up front
… the JSON/LD mediatype defines profile
… therefore we should be consistent with profiles work being done elsewhere.
<roba> i have an answer i think - most information elements are intrinsically profile-able - and these are orthoganal concerns.
azaroth: can we come to agreement
roba: in the case of profiles and mediatypes - orthogonal
… multiple co-existing profiles is just a fact of life, and shouldn't create problems
azaroth: they might be, but there is the capacity for overlap.
… there can be conflict
roba: if a profile specifies availability of a particular format, the need to describe what is available stays the same
azaroth: yes, it is nice to talk about what is available, but at some point a specific request has to be made. a selection has to be made
roba: and that is where the profiles negotiation needs to be aligned wiht your spec
antoine: quick reaction. most specific indication isthe one that's followed. mediatype. are people using this a lot?
azaroth: yes, there is an IANA registry with JSON/LD having 3 items registered and a few more from other areas.
antoine: are they used in practice?
<AndreaPerego> IANA profile URI registry: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml
antoine: how much data is supplied using these params?
azaroth: the implementations of annotation servers respect profiles
… other implementations will be able to give other profiles as expected
… we will use in Getty for asking for vocabs as SKOS or linked dataa
antoine: that is for the future. you could perhaps use HTTP conneg for the same effect
gkellogg: 3 profiles are defined in the JSON/LD namespace - expanded, compacted, flattened
… there are no normative requirements
… asking for a doc with expanded profile will return expanded, but specifying compacted doesn't specify the method
<azaroth> link gkellogg referred to: https://github.com/w3c/json-ld-syntax/issues/8
gkellogg: we need some way in the HTTP request to specify things like this. Without white listing there is security concern. It is a hole in the spec that needs filling
antoine: aren't we talking about different levels of profile?
gkellogg: yes, different cases
<roba> thats the point i was making
antoine: profiles in JSON/LD are specific to that mediatype, but other prponeg relates to the data
… if the pattern in JSON/LD is consistent wiht that approach then we could find some agreement
<Zakim> LarsG, you wanted to talk about preference order
LarsG: adressing antoine - there is a homonym problem rather than a technical problem
<roba> there may be two profiles at play here - one constraining the content and one constraining the schema - profiles may be combined and address different aspects
gkellogg: there will be registered and non-registered profiles, across different axes, and they might be specified simultaneously
roba: the conceptual model for profiles gives constraints on the standard, but not what they apply to . In the case of frames, how closely akin are they to profiles that describe schemas. Is the context doc that goes with a frame linkked to the import doc.....
<roba> its a shape then - specified as a template?
<azaroth> roba: Yes, it constrains the structure and graph boundary for the resulting json-ld document
<roba> so its a profile (constraint specification)... that should help align
gkellogg: ... frames don't allow subsetting of information. they allow structuring to get into the appropriate format. The canonical framing example brings together a book, library and author
roba: I think it should be easy to align these things conceptually - meaning you can use conneg as is, you're just wokring on a subtype of profile, the particular kind you're caring abobut
azaroth: is it valid to put a frame into its own profile - we want to avoid that
… we want ot have frames and contexts in the profile param of the JSON/LD medittype
roba: that is not the model we are using.
… the proposal is to create HTTP headers with those distinct semantics, but have generalised this in the spec to allow other approaches implemented by servers using parameters
antoine: I can see the theoretical beauty, but I would like to keep things orthogonal. DXWG sticks to the newly proposed header, and JSON/LD should work on a different header focusing on mediatype. I think keeping things separate is easier
azaroth: something like, the profiles that can be in the accept profile header must not conflict with those for mediatype
antoine: not necessarily conflict,...
<Zakim> LarsG, you wanted to talk about the media-type-independentness of accept-profile
LarsG: when we talk about profiles in the context of Accept-Profile they should be explicitly media independent
<antoine> not necessarily conflict: the idea is that there are two types (levels) of profiles, and these are negotiated/indicated in different places.
bigbluehat: has a refer header been considered? is in use in LDP
<Ralph> [DX profiles are media independent, that is]
<azaroth> LDP's prefer header usage: https://www.w3.org/TR/ldp/#prefer-parameters
bigbluehat: I think it also comes with a registry
… this is something i've seen in play in RESTful APIs
… my concern is that accept-profile might be confusing for people who are in this space, but prefer would be able to do the task without the confusion
<roba> the term profile is consistent if and only if you dont capture it and redefine it to be something very specific - like profile of a media type. "frames" are types of profiles
Jaroslav_Pullmann: responsing to LarsG. we were talking about potential implementations. when you referrefd to them as being independent of mediatype
<roba> room dropped out of webex
LarsG: we have also discussed a profile as an abstract thing, but there are multiple constraints (xsd, shacl) for the same constraints. different mediatypes, equivalient content
LarsG: coming back to the prefer header. we have been looking but it doesn't fulfill the use case because if you don't get a preference-applied header, what does that mean
… there is no way to return info that the preference was heard. There is no feedback.
bigbluehat: there could be a useful status code
… this goes beyond content negotiation
sandro: do you need this info?
LarsG: yes, we need to know if it was misunderstood
sandro: but this is the same as if the client gave no preference
<Ralph> [I wonder if the handling parameter on Prefer is useful as a signal from the requestor on what sort of flexibility the server may consider]
bigbluehat: the preferred header has been used in WebDAV - so perhaps look there
… look at 8144
… I've seen used with hypermedia JSON formats, both correctly and incorrectly
sandro: there is a difference between prefer and require
<Zakim> azaroth, you wanted to ask about json-schema and json
azaroth: if there was a constraint expresed in JSON schema, would that be refused from the accept header because it is mediatype specific?
LarsG: if you only want JSON you could use the JSON URI as a profile URI. It would break the model, but for the sake of conneg by profle, if the server was set up to use that as a profile URI it would work
azaroth: but because of the mediatype it couldn't be put in the header
LarsG: you could treat the JSON schema URI as a profile URI - punning
<roba> every standard is a profile of itself - so this is OK
LarsG: there should be a URI and a q value. setting up the server to serve JSON only and it would work
<roba> same as A rdfs:subClassOf A if X a standard then X profileOf X
<roba> lets have that written up as a use case please
Jaroslav_Pullmann: question about coverage
<gkellogg> The use of an actualy profile, such as a json-ld context or frame instead of #compacted or #framed may imply a profile, but is not as direct as using an actually registered profile IRI.
Jaroslav_Pullmann: representations of a resource. how do we express the coverage
<gkellogg> It also potentially exposes the server to evaluate something which may be malware
LarsG: look it up
roba: there are nuances here - I would like written use cases so we can check fully later.
<Zakim> azaroth, you wanted to try to give example of profile's media types re Jaro
roba: Nothing specifies that profiles need to be globally registered, just that there needs to be a dereferencable form - keeps things lfuid
azaroth: example of profiles mediatypes
roba: if profile specifies that is must be available, there can be validation that a server can provide that one. if you claim you conform to the profile you have to provide all 3 formats
bigbluehat: the "if-" space is another negotiated space. if-matched, etc. Worth looking at
Jaroslav_Pullmann: in response to azaroth and roba. a consistent set of constraints should be applied.
Action: azaroth to write up something for others to reflect on - places in issue 261
<trackbot> Created ACTION-251 - Write up something for others to reflect on - places in issue 261 [on Robert Sanderson - due 2018-11-02].
azaroth: profiles and mediatype independence is what we need to consider to prevent a wedge between the two pieces of work
<roba> * I will depart now unless anything urgent you want from me..
<roba> * thanks all
kcoyle: we've got two main things: comment we received, and what we want to do next
<AndreaPerego> For our records: WebEx meeting was closed, and we cannot restart it - sorry for people who plan to join
kcoyle: we've done a bit of planning as we went along
… let's look at the comment we received
kcoyle: different points - not happy with idea of services, - documenting different kinds of distributions
AndreaPerego: first point: why services as first class citizens
… then overspecification of distributions on the original version of DCAT
… distributions pointing to a file or to a service/API endpoint
Jaroslav_Pullmann: relationship between dataset and profiles
AndreaPerego: it is broader - more than one distribution of a dataset that are not equivalent
kcoyle: looking at the first issue about services as first class citizens
alejandra: shall we look at the use cases for this?
PWinstanley: we've been taking on board stuff from the spatial data on the web
… inclusion of services and datasets
… reducing axiomatization
… we haven't been talking about DCAT on isolation, but on the context of profile notion
AndreaPerego: one of the examples is from the geospatial domain
… but DCAT is domain specific
… the service could be service more than one dataset
… for SPARQL is the same, you need to be able to make queries
… the spatial use case is important, but it is not the only use case
… looking at what we have in DCAT, we are not breaking the original version
… we tried to be backward compatible
… the services are in addition to what we had
… you can use the distributions if that's enough for you
… we are not changing DCAT dramatically and have a bias on favour of services
… we should understand better the points raised
DaveBrowning: in my domain, I probably want a data catalog to go in both dimensions: the mechanisms to get hold of the data are in several scenarios as important as the raw data
… people will look at the data and at services and their characteristics
… treating services as first class citizens seems to me the right way
… about distributions, we have more work to do and that might help to address the issues here
… relationships between datasets/services and distributions
… with different rights and obligations
… I think there are examples outside the geospatial world that justify having services as first class citizens
Jaroslav_Pullmann: ID22 use cases also relevant
… this is what we've done in the industrial data space
… implemented a simple representation
<AndreaPerego> UC Jaroslav_Pullmann refers to: https://www.w3.org/TR/dcat-ucr/#ID22
Jaroslav_Pullmann: my undersanding of this request is to support dynamic resources, describing APIs
brinkwoman: in the spatial data on the web best practices we saw that a user looks for data
… and then for distributions and then to a service/download way
… so dataset -> distribution -> service is a logical way of thinking of this
… so I see why service needs to be a first class citizen but maybe you need a good example
… to show how these classes should be used
… I think that is what Clemens was getting at
PWinstanley: in a particular domain you could use a profile
DaveBrowning: you can profile DCAT too
… but there are other examples
brinkwoman: isn't still a good idea to explain the model a bit more?
jtandy: Clemens emphasizes that is a data catalog
… he said that DWBP when you are exposing data through an API
… says tag a dataset to an endpoint
… 100s of datasets to an endpoint
… RESTful pattern in OGC
<Zakim> jtandy, you wanted to present Clemens thoughts about the relationship with datasets and services
jtandy: the endpoint is a child relationship to the dataset itself
… the mistake he is encouraging to avoid is when not using resource-oriented approaches
DaveBrowning: listening to this question - there are issues related to being about data catalog and being the data exchange working group
<kcoyle> do you want me to turn on my sound? you may hear something
DaveBrowning: we need to get the right balance
jtandy: there are services that are not always attached to data
… resource-oriented view - there are some services that don't fit that model
… the general pattern is find the data, and then find the access point
… is the service special type of distribution
<PWinstanley> alejandra: DCAT 1 didn't have any of this service stuff, but we need more explanation on the data services, which can be catalogued, but they giva access to the data
<PWinstanley> ... I understand the concerns about focusing on services, but we are talking about *data* services
jtandy: at least clarification is needed
<PWinstanley> jtandy: as Clemens it talking about this then it is clear that some clarification is needed
<PWinstanley> ... also there is the idea of a data set which can only be engaged with as a distribution. If you start to put services at the same level then it becomes complex very quickly
AndreaPerego: we need to clarify that people case use the data services if they want to, and also there must be a clarification on how to use the services
… and if they replace the distributions or not
… I see an increasing amount of catalogs with a tab for the data and a tab for the APIs
… they want to be able to use the APIs
… this idea of having access to reusable data services and APIs is something that may be happening
… there was a discussion on broadening the scope of DCAT
… catalogs have not just datasets, also events, etc
… should we talk about catalogs of resources?
… it may be useful to have a way of filtering the different resources types in the catalog
jtandy: in museums, they have datasets with information about the physical objects
… what resources are you trying to catalog...
Jaroslav_Pullmann: there is no link between services and datasets
… it is not actionable
… how this relates to the dataset
… the endpoint description is an open API
… and then there is no link on resources
… in a service-oriented world we have resources providing services
PWinstanley: should URIs be opaque or should be human-readable?
… in the DCAT work seems that is for human consumption, but we are dealing predominantly with machine consumable information
… it is important to have the distinction between how machines would approach this
… and access services
… we should be building an ecosystem of machine-to-machine interaction
… where humans have minimal input
kcoyle: I believe that what needs to be done is to add a justification for services
Action: AndreaPerego to add some text justifying the need for services
<trackbot> Created ACTION-252 - Add some text justifying the need for services [on Andrea Perego - due 2018-11-02].
kcoyle: distributions are not defined in a way that are not specific
… somewhat related
… it would be good to know what he thinks is lacking
AndreaPerego: distributions pointing to a service
… have some additional information having consumers knowing type of endpoint (e.g. SPARQL)
… the work done for the services and for the distributions was done in parallel
kcoyle: would it be ok to ask him to clarify what he thinks is missing?
AndreaPerego: dcat:Distribution is pointing (with dcat:accessService) to dcat:DataDistributionService
… and there is a link to the possible description to the interface
<PWinstanley> we can invoke http://w3c.github.io/sdw/bp/#convenience-apis to simplify the model (via a profile)
AndreaPerego: OGC services or open APIs and so on
DaveBrowning: there are still things that we need to do about distributions and that will flesh out more
… it would be interesting to know what he would prioritize about distributions
Action: DaveBrowning to reply and start the conversation with Clemens
<trackbot> Created ACTION-253 - Reply and start the conversation with clemens [on David Browning - due 2018-11-02].
Jaroslav_Pullmann: we are missing the operation of the service
… a service providing such a distribution about a dataset
DaveBrowning: that could be pointing to a swagger API / open API registry
Jaroslav_Pullmann: but there is no link, how to parameterize the API
kcoyle: where does this fit in to the DCAT work?
… would this be addressed for the final draft?
<Zakim> jtandy, you wanted to suggest creating issues in the DXWG repo for this
jtandy: my suggestion would be to create a test case, whereby you have an API register in swagger hub and you want to discover it
… if navigation through that swagger hub service catalog gives you everything you need, why do you need anything else
… test and see
jtandy: what we found works quite well is to raise a github issue for each of the things you want to have a dialog on
action DaveBrowning will create github issues related to this discussion
<trackbot> Created ACTION-254 - Will create github issues related to this discussion [on David Browning - due 2018-11-02].
PWinstanley: there are other places where complexity of an underlying situation can be simplified
PWinstanley: we could reuse the convenience API
… this is not unique to us
kcoyle: issue about distributions/ profiles
DaveBrowning: there is an issue about informationally equivalent distributions
jtandy: in particular, he is suggesting more guidance on what a dataset object is
DaveBrowning: if they are not informationally equivalent, how would you model them
… we will provide the ncessary guidance
kcoyle: media type of the distribution, profile and profile negotiation, would it make sense to describe the profile that a distribution supports
alejandra: this is the conformsTo in dcat:Resource
discussion on typing the resources as being a profile
AndreaPerego: information loss issue
… we had lots of discussion on this point
… people in different domains are dealing with this in different ways
… different ways of addressing these issues
kcoyle: planning about next steps
kcoyle: DCAT - response to comment and priorities of issues
… documents for profile / content negotiation and ontology
brinkwoman: what is the timeline? when people need to comment about DCAT?
DaveBrowning: it would be useful to have comments now so that it gives us an opportunity to respond
… we are planning to have something ready by mid January
brinkwoman: I will get someone from my organization to comment
<Zakim> jtandy, you wanted to talk about publication tempo
jtandy: we found really useful to set up a publication tempo
… because it will allow people to engage your broader community to give feedback
… other WGs wait till they have something substantial/perfect and get feedback too late
<AndreaPerego> [meeting adjourned]
Failed: s/sscribenick: PWinstanley//
Succeeded: s/desrciptions /descriptions /
Failed: s/rendering of the documentation/rendering of the documentation and the execution of the code/
Succeeded: s/talk about profiles/talk about profiles in the context of Accept-Profile/