See also: IRC log
<annette_g> scribenick: annette_g
kcoyle: no need to revise the agenda
<dsr> ic
kcoyle: the first group are gathered under "dataset distributions". Some may be more pertinent than others. Start with use case 1.
Makx: a lot of people produce zip
files as distros. But you don't know what's in it. What kind of
formats have been packaged in it?
... a lot of people argue that the right way to do that is to
have zip files within zip files. We got into a discussion where
you have an extra field "representation technique" to explain
that. Is there a way to describe packaging better?
<Zakim> dsr, you wanted to ask about URI params for addressing inside zip files
Dsr: it sounds like something could be done in DCAT where you talk about the kind of distribution.
<SimonCox> zakim: who is present?
Makx: I have no opinion on how to
do it.
... the issue is that just getting a zip file requires them to
download before they can know what's in it.
<SimonCox> zip file might contain xml, which follows the OMXML application of GML - is it zip, xml, gml or omxml??
Makx: the solution could be to have a required field that tells what's in the zip file.
Jaroslav_Pullmann: the issue is the type of file
Makx: the media type is not the issue, you need to say what's inside
SimonCox: taking an example fro geospatial data, if you have observational data in GXML, that might all be zipped up. So even a serialization description can use four different file types. If you impose too rigid a number of levels, you can get tied up in knots.
<phila> SimonCox highlights the issue of profiles within a serialisation within a package
antoine: Makx , do you think one might do a csv distribution that is explicitly listed as containing csv?
<Zakim> LarsG, you wanted to say that OMXML is propile of GML that is a profile of XML
Lars: oops, I missed that, can you fill it?
<kcoyle> lars: this is media type vs content type
SimonCox: there's also overlap with the use case from yesterday about dataset types
<LarsG> LarsG: Just iterating myself, SimonCox's point is about media types vs profiles and then in this particular case we have the packaging, too
<Zakim> danbri, you wanted to note a design that came up in packaged webapps - https://www.w3.org/TR/2013/WD-app-uri-20130516/#fragment
LuizBonino: we should focus on the actual data we want. We could have the distribution layered, so that the top layer explains the content format.
<dsr> This sounds like a question of the model around metadata for datasets, distributions and data record. If we don’t want to model the structure of the resources in DCAT, we need a way to identify the profile/schema language that can, e.g. as a hierarchy of typed resources
<LarsG> ... and I could add that content type should indicate the media type, not the packaging
<SimonCox> multipart mime-types?
danbri: schema.org tried to handle this. URI scheme for pointing into the contents of a zip file.
Keith: consider content negotiation
Jaroslav_Pullmann: it could be integrated into it
<Zakim> phila, you wanted to talk about Web publications
<phila> Publishing Working Group
<danbri> annette_g, rather - at Google we tried to build something using DCAT-or-Schema.org and CSVW, but when we had *multiple* linked CSV tables and a csvw-meta.json file - we didn't understand how to model those as a "distribution" unless it was zipped into one file.
Phila: a new WG is starting, publishing working group. They want a single URI for a whole package.
<danbri> (here's a sketch of csvw for a *single* table treated as the main topic of a Dataset ... not sure if it is better done as a distribution or distributions. https://gist.github.com/danbri/154e1b98240fe7fe60c26bd5c04d1325)
Makx: I just have this simple use case that people are actually struggling with. We can address that or try and solve everything. Do we want to provide a simple solution for simple cases, or not?
kcoyle: are we ready to vote? More comments?
Silence ensues
<kcoyle> PROPOSED: Accept UC ID1
<Thomas> +1
<SimonCox> +1 (to accept all use cases ;-) )
<alejandra> +1
<newton> +1
+1
<LuizBonino> +1
<PWinstanley> +1
<Jaroslav_Pullmann> +1
<Keith> +1 accept all use cases
<Ine> +1
<antoine> +1
<Makx> +1
<LarsG> kcoyle: +1
<phila> 0 (not currently empowered to vote)
<danbri> following Phil's link, -> https://www.w3.org/2017/04/publ-wg-charter/"Packaged Web Publications" for TAG work on this.
<danbri> +1
<DaveBrowning> +1
RESOLUTION: Accept UC ID1
<SimonCox> Maybe we should change the motion to 'move on to brief discussion of next use case' ;-)
<dsr> +1
<Caroline_> +1
<LarsG> Just noting that the discussion of content vs packaging is essentially http Content-Type vs Content-Encoding
kcoyle: next is use case 25, synchronized catalog information
Jaroslav_Pullmann: this is about how the data might be published and whether there are restrictions.
It would prevent copying of the dataset without paying a license fee, etc.
We talked to some customers who are interested in this.
This holds for the open data domain as well.
<danbri> (more re dataset packaging, https://w3ctag.github.io/packaging-on-the-web/#downloading-data-for-local-processing)
PWinstanley: events for transitions are relevant here
kcoyle: are you offered get to create a use case?
<kcoyle> ACTION: Peter will create a use case for event,transition [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action01]
PWinstanley: I guess I am
<trackbot> Created ACTION-21 - Will create a use case for event,transition [on Peter Winstanley - due 2017-07-25].
Makx: Jaro, are you really talking about dataset descriptions or the data itself?
Usually people don't mind having descriptions shared.
<Zakim> phila, you wanted to talk about ResourceSync
Jaroslav_Pullmann: this is regulating access to the metadata. And distribution of it.
<phila> ResourceSync
phila: I went to Geneva and while there Herbert van de Sompel gave a tutorial about "resource sync", which enables you to have a master an distributed copies with access control.
I think that would be outside the scope of DCAT, but it's a useful discussion point to say here's how to do this.
Makx: wonders whether we should mention this in Linked Data Notifications.
phila: yes, it does link to that, that would be another way to do it.
S/Makx/Antoine/
<antoine> https://www.w3.org/TR/ldn/
kcoyle: do we want to vote to accept or to declare it out of scope?
<antoine> s/this in data identifications/Linked Data Notifications
Keith: to what extent can we use license and rights for this?
In theory it should be possible to specify with license and rights.
Jaroslav_Pullmann: it's harder to get it to apply to the metadata
Makx: reacting to Keith, the licenses and rights in DCAT are for the data, not the metadata. You can assign through catalog records, but that's not correctly done.
Keith: what about considering a catalog as a dataset?
Makx: catalogs are not datasets.
Phila: that's fighting words ;)
<Zakim> LarsG, you wanted to talk about licensing of metadata
<Zakim> danbri, you wanted to ask whether redhat linux v5 is a dataset or a catalog?
danbri: is red hat distribution number 5 a dataset or catalog or both?
Makx: I don't know
If you have an edge case, then you have to look at it. But it doesn't help to start mixing up the hierarchy of DCAT.
LuizBonino: isn't that what we are doing here`?
kcoyle: well, we don't want to break what already exists
Makx: right, we don't want to upset people
<kcoyle> PROPOSED: Accept ID25
<Makx> +1
<Jaroslav_Pullmann> +1
<antoine> +1
<LarsG> -1 it think it's out of scope
<danbri> I'm not interested to tear everything up and start over - I just want to know how to apply DCAT to a fairly obvious use case - packaged sofware distributions. It is totally fine to conclude that DCAT cannot handle this.
<Thomas> -1
<PWinstanley> -1
-1
<LuizBonino> My point is that in several cases, people are using DCAT in a certain way exactly because things are not clear or incomplete, and if we are block because of this the situation will persist.
<Caroline_> +1
<Keith> -1: neds further work
<Ine> 0
<DaveBrowning> -1
<SimonCox> +1
<LuizBonino> +1
<Makx> @dan, we weren't talking about packaging right now
<danbri> -1
Jaroslav_Pullmann: there is no statement of whether dataset metadata might be freely distributed.
<danbri> Makx, I took you to be suggesting that Catalog and Dataset should be treated as owl disjoint forever. But we can pick this up elsewhere, you're right it's not core to this UC.
<alejandra> +1
Phila: resourcing and subscribing
are application specific
... this is important, and we could publish a note on it if we
want.
That would be valuable. But it is out of scope for updating DCAT and profiles work
<kcoyle> PROPOSED: UC ID25 is out of scope
<LarsG> +1
+1
<antoine> -1
<Makx> -1
<Thomas> +1
<Jaroslav_Pullmann> -1
<SimonCox> -1
<PWinstanley> +1
<LuizBonino> -1
<Makx> -1 meaning I think it is in scope
<Caroline_> -1
Dsr: looking at the text, you have catalogs and datasets. I given resource may appear in multiple categories. This use case seems orthogonal.
S/I given/A given/
alejandra: if the use case is just about synchronization, I agree that it's out of scope.
<dsr> catalogues need to remain in sync with the data sets they describe, but the possibility that a given dataset/distributions are in multiple catalogues is orthogonal to that.
Jaroslav_Pullmann: representing the relationship would be in scope.
S/Jaroslav_Pullman/Alejandra/
Keith: the relationships can be very complex, and that's quite typical. People do that to get exposure. I think it is a relevant use case.
Thomas: is trying to find a way to address the example of when you want to describe the current state of something that has a history.
antoine: I made this to address policy aspects, like encryption. We only have one case on access policies (17), and maybe that's a bit too narrow. The problem of having the dataset in different catalogs may also create situations that need to be addressed. This wasn't about synchronization.
<Makx> @Jaroslav, happy to help on ID25
kcoyle: maybe Jaroslav_Pullmann can edit
<Jaroslav_Pullmann> thanks Makx! I'll supply a new proposal
<Keith> @Jaroslav, happy to help on ID25
<kcoyle> ACTION: on Jaroslav_Pullmann to edit and bring back to group [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action02]
<trackbot> Error finding 'on'. You can review and register nicknames at <https://www.w3.org/2017/dxwg/track/users>.
<phila> phila: There was a paper/talk on duplicate entries in catalogues at the SDSVoc workshop by the folks working on the EU data portl https://www.w3.org/2016/11/sdsvoc/agenda#p24
kcoyle: next is 32, relationships between datasets
alejandra: this relates to the previous discussion, relationships between datasets.
We need the ability to represent relationships and aggregations, etc.
Versioning is also related to this.
Thomas: how generic do you see this use case?
alejandra: it may not be possible to identify all the relationships in advance, but some are known.
Thomas: we will need some guidance on this. I'm worried about everyone adding all relationships.
kcoyle: the question is whether we need to have some control over at least a core of relationships
<SimonCox> http://patterns.dataincubator.org/book/qualified-relation.html
DaveBrowning: this is somewhat like provenance.
I don't see how this would end up being expressed in the same way.
Thomas: it's a nightmare for governance
kcoyle: we don't have to have an answer today
Makx: this is one of the most hairy issues for application profiles. We were hoping this group would have an answer for it.
<riccardoAlbertoni_> +1 to Makx
DCAT doesn't consider any relationship between datasets. This is an opportunity.
<danbri> Makx, where's the dcat-ap mailing list archive?
<Zakim> phila, you wanted to talk about relationship management
phila: +1 to Makx. The relationships are important to state, but they may not be the same across domains. We do have to say something. We provide a framework and a few explicit ones, then it's up to profiles
<LuizBonino> +1 to Makx. We shouldn't shy out because things are complex. In my opinion is better to face complexity and try to come up with a generic and elegant solution than to over simplify and come up with a useless solution.
Jaroslav_Pullmann: DCAT so far does not have structure within the datasets, like aggregation of data.
Keith: I agree with phila. A framework can have the role and temporal bounds.
alejandra: I put a link for data cite. They have some things that we could consider as solutions.
<Zakim> LarsG, you wanted to ask about a core set of relation types
LarsG: do we define a few datatypes or leave everything to profiles? Maybe we adopt what datacite already has.
Thomas: I agree with Phil, we define a few and let people describe in profiles.
Keith: reasons of privacy and security say you should keep that stuff separate.
<SimonCox> annette_g: I think LarsG said relation-types, rather than datatypes?
<kcoyle> PROPOSED: accept ID32 as in scope
<Thomas> +1
<DaveBrowning> +1
<LuizBonino> +1
<Jaroslav_Pullmann_> +1
<Makx> +1
<SimonCox> +1
<alejandra> +1
<Ine> +1
S/datatypes/relation types/
<Keith> +1
<riccardoAlbertoni_> +1
<Caroline_> +1
+1
<LarsG> +1
<antoine> +1
RESOLUTION: accept ID32 as in scope
kcoyle: ID34 is next
More about relationships
<alejandra> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID34
<phila> Actually, I don't agree that a CSV and the Excel file it came from are the same, *unless* the annotations are copied in the CSV as well
<Caroline_> scribe: Caroline_
<LuizBonino> I think that it is related to how strict is the definition of dataset. For instance, if a distribution of a dataset contain different data points, wouldn't be different datasets or version of the dataset?
Jaroslav_Pullmann_: this is a distribution but it is not a change of the dataset
<LarsG> scribeNick: Caroline_
the data should remains the same
a subset of the data is prefigure
I support the idea that the data should remain the same because the distribution is just the interface
DaveBrowning: I agree with Jaroslav_Pullmann_
we introduced the idea that all the distributions of datasets ??
it does make easier to discover
the same thing in each dataset
the distributions telling you in different ways seems to work
relationships among distributions
I think this is important
<annette_g_> DaveBrowning: we need to be quite clear about what we intend
we need to be clear in the DCAT about what we intend and what we don't intend to people doing here
<annette_g_> LarsG: we have the problem of publishing the same dataset in two different formats
LarsG: we publish the same datasets in two different forms
<annette_g_> I can scribe now
the datasets contains the same entities but the descriptions can vary
<scribe> scribenick: annette_g_
There is a question whether those are the same dataset of not.
Makx: I'm in favor of what Dave
said, too.
... I don't want to blame anybody. But I"m very much in favor
of what DAve said
LuizBonino: when we have a distribution composed of many different loose files, the summation of files composes the distribution.
Keith: does it help to think of physical terms?
Jaroslav_Pullmann: yes, they are physical, and there is an interaction logic. We don't have push semantics here. They can differ in serialization and interaction logic.
Kc
<Keith> I said distributions are physical, all distributions of one dataset have the same conceptual, we can discuss logical
kcoyle: are we ready to vote?
More silence ensues
<kcoyle> PROPOSED: accept ID34 as in scope
<Thomas> +1
<Makx> +1
<riccardoAlbertoni_> +1
<LuizBonino> +1
<LarsG> +1
<Ine> +1
+1
<Caroline_> +1
<PWinstanley> +1
<DaveBrowning> +1
<Jaroslav_Pullmann_> +1
<dsr> +1
<newton> +1
<danbri> +1 to Jaroslav's point, that's how we got stuck trying to document how to integrate multi-file CSVW dataset distributions for Google dataset search
<Keith> +1
<danbri> and +1 for vote
<antoine> +1
<alejandra> +1
<SimonCox> +1
RESOLUTION: accept ID34 as in scope
<danbri> ID7: https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID7
Let's look at ID7 while Simon is here
^that was kcoyle
<Caroline_> s/ˆ/
S/Dan briber/danbri/
SimonCox: can we tease out some more of the semantics about what's inside a dataset? Schema.org introduced ??
<danbri> SimonCox - yes - I can see SOSA-in-Schema.org replacing that
One of the most important things for discovery is that a single dataset may have more than one format in it.
<danbri> http://pending.schema.org/variableMeasured was a tiny step towards a complex topic, consider it a "stop gap"
<alejandra> related issue in schema.org: https://github.com/schemaorg/schemaorg/issues/1471
Jaroslav_Pullmann: was wondering about the "entity of interest", if this is not part of the context. The socioeconomic context is important, the time, space, society.
LuizBonino: I would love to see this included, but I don't think it's in the scope of core DCAT.
We can use a profile to deal with it.
<alejandra> +q
<Zakim> phila, you wanted to ask whether an example for any dataset would answer ID7
Phila: I understand the requirement, and I wonder if a generic field "example" would do it? Like VOID has.
<SimonCox> 'dimension' is OK - comes from QB world
alejandra: we had this same issue and created a new entity that we call "dimension" but not "variable".
SimonCox: phila and Jaroslav_Pullmann were challenging the feature "entity of interest". The observable variables are important.
Certainly for observational data
LuizBonino: to clarify, one example of a description that I would like is to have a dataset with info about genes and diseases, and to see that there is a gene/disease relationship in the dataset, and that it has an open license, find grained search possibilities.
<SimonCox> Can't hear - interference on line
Jaroslav_Pullmann: can you comment on the distinction. Properties are part of semantics, what do you think about considering the entity of interest as part of the context?
We are still missing this reference.
<AndreaPerego> scribe: annette_g
Jaroslav_Pullmann: is it maybe worth having a new use case?
<phila> Geospatial 'Leaking into W3C world?' More like making sure we're not just relying on osmotic pressure to ensure mixing :-)
SimonCox: the use case was made general, and I think we have to accept that any time we're developing a record, there's a prerogative of the indexer/cataloguer, as to what descriptors will help users. The goal was to provide some practices or some hooks that allow people to be as expressive as they choose.
Jaroslav_Pullmann: but the world phenomena are not part of the semantics but the context
Reference to the socioeconomic environment is not covered in an other use case.
<Zakim> danbri, you wanted to ask SimonCox if "a dataset record" is on the underlying structure of records (e.g. rows in a multi-tabular distribution), or the real world entity
danbri: I'm generally massively supportive of this use case. Google wants to make datasets easy to find, allow one to look deeply inside them, to solve real problems.
What this working group does is going to be more conservative. We do care about records and entities.
SimonCox: I'm not sure I"m getting the nuance of the question.
danbri: imagine a dataset of public toilets. Are we interested in the number of rows or the number of tables?
<danbri> imagine a distribution consisting of 4 tables which combine to describe 142 public toilets in Bristol City Council area. There might be 22 rows, 100 rows, 12 rows and 8 rows in those tables. Which are the records? The 142 toilet-descriptions, or the set of (different sized) rows?
<Caroline_> scribenick: Caroline_
<danbri> I'd suggest it's "in scope for dcat" in that dcat should explain where it fits on this spectrum and allow CSVW, Data Cube etc to cover more details.
SimonCox: i'd be happy if we got that much in DCAT
<annette_g__> kcoyle: I'm wondering if this is something we need to decide today
<LuizBonino> +1 to danbri . I'd like to see a hook in DCAT to whatever description mechanism of the record will be
<scribe> scribenick: annette_g__
<Thomas> +1 to luiz
SimonCox: I see a lot of what we're doing is patterns and practices
Makx: on the last point that Simon made, we also filed requirements to promote stuff that is in data cube, like dimensions and measures, to dataset description.
<danbri> (the caveats discussion also fits here ... attachment points for caveats exist all along the spectrum)
<kcoyle> PROPOSED: accept ID7 as in scope
Keith: I think it's in scope, and important, and what we're talking about is formalizing description. I would hope that what exists in DCAT is useful for Dublin core purposes, and the profiles can handle this differently by domain.
<Thomas> +1
<LuizBonino> +1
<Makx> +1
<Jaroslav_Pullmann> +1
+1
<Ine> +1
<SimonCox> +1
<dsr> +1
<antoine> +1
<newton> +1
<Caroline_> +1
<AndreaPerego> +1
<DaveBrowning> +1
<LarsG> +1
<PWinstanley> +1
<Keith> +1
<riccardoAlbertoni_> +1
<alejandra> +1
<danbri> +10
RESOLUTION: accept ID7 as in scope
<SimonCox> Good-o
<Caroline_> ----Break for 30min----
<danbri> Keith, SimonCox et al - did you see https://www.w3.org/TR/2015/REC-csv2rdf-20151217/? e.g. https://github.com/w3c/csvw/blob/gh-pages/examples/simple-weather-observation.md shows it used to map weather data into qb:, ssn:, qudt: based graph structures.
<danbri> alejandra: http://www.greggkellogg.net/2015/04/implementing-csv-on-the-web/
<SimonCox> danbri: yeah - skimmed it a year or so ago. Very Jeremy. Very much for the RDF true-believers.
<SimonCox> Jeremy is so cute when he gets all pedagogical.
<SimonCox> RobA is at band practice (trumpet!) He intends to join the call 45 minutes from now.
<SimonCox> I'm going to leave the call now to continue my recovery (i.e. get horizontal)
<Caroline_> chair: Caroline_
<danbri> scribenick: danbri
<scribe> scribe: Dan Brickley
<Caroline_> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID41
kcoyle: This is probably not
complete. I looked at UCs, didn't see coverage around profiles.
This comes from both Dublin Core's work around application
profiles, and also work around RDF validation.
... profile doc should include info such as mandatory-ness,
cardinality, dependencies, and/or/not etc in dataset.
... possibly leads us to being able to derive both input forms
as well as validation rules from the vocabulary.
<Zakim> phila, you wanted to talk about base assumptions as requirements
phila: This looks like either "we haven't a UC for doing this so let's write it". But you sort of have in that the charter (based on earlier consultations). No need to invent a UC since we're chartered for it.
karen: there was a need to say more about what a profile is
phila: ok to include within it assumptions that were there [in the charter]. Otherwise you end up writing UCs to make explicit absurd things like "we'll use the Web".
caroline: any more comments?
AndreaPerego: to say that my
understanding of this UC is that we may need to make a kind of
recommendation for provision of documentation, cardinality etc
in data schema.
... this is not always the case esp. with RDF
vocabularies
... this is indeed included in the charter, but would be nice
[...] description of the constraint to be used
caroline: noting that it's in the charter, assuming we'll keep the use case? (q to AndreaPerego )
<antoine> +1
AndreaPerego: I am supportive of the UC. It goes a bit beyond the requirements from the charter.
Jaroslav: If we are going to negotiate profiles and kinds of data, we'll need something like this to discover profiles. They are not predefined, they are custom.
<Jaroslav_Pullmann> Jaroslav_Pullmann_Pullmann has joined #dxwg
kcoyle: I don't think that the UC gives you a way to discover profiles. It is about the content of the profile document. We will talk about conneg later.
Jaroslav_Pullmann: [missed - can't hear from here]
UC41 discussion continues.
kcoyle: how are we going ... these are some ideas, functions that I feel are needed in a profile document, there are probably others. How are we going to tease those out?
Ine: I have comments from
colleagues. Sees need to make profiles more structured.
... ... part of this usecase.
<Zakim> LarsG, you wanted to talk about ODRL
<LarsG> https://w3c.github.io/poe/model/#profile
LarsG: wanted to point to another
WG at W3C, Permissions/Obligations/Expressions (POE). They also
talk of profiles in context of how you describe different
rights and their extensions.
... they also talk about profiles, they have some interesting
use cases for profiles that we should look at as well. Similar
- extending a core vocabulary, making certain restrictions,
what you can/can't do. It is nice in that you are not
restricted to use RDF, but can use plain JSON and XML
representations also.
<Zakim> antoine, you wanted to talk about the EDM case
LarsG: not hard-coupled to a particular validation language.
antoine: Similar remark. Probably
could be useful to have a look at the various profiles that are
around. People in this WG may have their own, e.g.
DCAT-AP.
... we have tried to include some of these elements under the
Europeana data model.
... could be useful to understand some evidence of what is
needed in an ecosystem [like europeana's]
... also some links to the DCMI work
Jaroslav_Pullmann: wondering if
there is not a formalization of the constraints e.g. a schema
or an expression constraint language.
... to explore constraints in a machine processable way.
kcoyle: I assumed it would be machine processable but didn't say that here.
Jaroslav_Pullmann: There could also be free text restrictions.
kcoyle: if I sat and made a
handful of UCs, one would be the possibility of generating
human user documentation from the profiles.
... should be readable, easily creatable by non-coders.
... I can add those as usecases.
... definitely what we looked at in the validation area.
<Makx> An initial SHACL expression of DCAT-AP was recently published, see https://joinup.ec.europa.eu/node/146653/
<Zakim> danbri, you wanted to mention I18N
<phila> danbri: That last piece, going from machine readable to human readable, is good for i18n, but we should be aware that there may not be a 100% correlation
kcoyle: whole other discussion,
about how this relates to the 2 RDF validation systems active
around W3C, SHACL and SHEX.
... do we require that profiles be in RDF
danbri: DCAT is RDF?
phila: Yes and no! See line in the charter.
"That would be an ecumenical matter."
phila: DCAT is currently an RDF vocabulary. "DCAT is formulated as an RDF vocabulary... etc"
see https://www.w3.org/2017/dxwg/charter
<Zakim> LarsG, you wanted to talk about the difference between profiles and schemas
phila: noting that POE is RDF-oriented.
LarsG: profiles and schemas are
not the same
... shacl works at an rdf level, you could also have an xml
schema
<roba> schemas also need profiles to set content rules
phila: RDF and XML schema names are unfortunately similar, can we blame someone in the room?
danbri: [gracelessly blames saintly Ralph Swick]
LuizBonino: .... can use shex/shacl to verify compliance
DaveBrowning: q re context/organization. What is the relationship between the profile work in POE and here?
phila: ODRL/POE ... ODRL has
notion of profiles since 2002. Not a new concept. What I said
to them: this WG is defining what W3C means by a profile. [of
ODRL]
... ODRL has a tiny core and is essentially unusable without
using a profile.
Caroline_: Thanks for the discussion. Let's vote on whether UC41 is in scope for our work.
proposal: UC41 is in scope.
+1
<roba> +1
<AndreaPerego> +1
<Thomas> +1
<alejandra> +1
<dsr> +1
<riccardoAlbertoni_> +1
<Caroline_> +1
<antoine> +1
<newton> +1
<LuizBonino> +1
<annette_g___> +1
<DaveBrowning> +1
<Jaroslav_Pullmann> +1
<PWinstanley> +1
<LarsG> +1
<Keith> +1
<Ine> +1
<kcoyle> +1
<Makx> +1
RESOLUTION: UC41 is in scope for DXWG.
<kcoyle> ACTION: kcoyle to complete set of profile use cases [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action03]
<trackbot> Created ACTION-22 - Complete set of profile use cases [on Karen Coyle - due 2017-07-25].
<roba> * here hear
<Caroline_> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID5
/www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID5//www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID5
roba: ID5: If a dataset itself
can also conform to profiles just as DCAT's specification can
be profiled, datasets themselves might be available via
multiple encodings, and also by multiple schemas in slightly
different profiles (but same basic dataset).
... considered in DCAT terms, consider a catalog of DCAT
instances which are datasets, ... multiple profiles of DCAT
that can be served by that catalog. So the catalog would need
to be able to say which profiles are supported.
... so as long as profiles have identifiers, it should be
possible to have at some stage a property which tells you which
profiles are supported.
phila: Rob, are you thinking Web capabilities service?
roba: Not necessarily. UC could
be DCAT instances polymorphic. E.g. an instance inside Frence
geological agency will have content to meet French agency
needs, plus INSPIRE
... you'll see same pattern inside every dataset. I don't think
a separate service is needed beyond the DCAT records.
phila: We debated earlier whether catalogs can be datasets.
<Makx> -1
roba: I hope so, they have same characteristics.
Makx: (remotely in IRC), -1 to this (as elaborated earlier).
Ine: A need ... thinking of new version of DCAT, to describe which version, also of DCAT itself.
phila: You need to know which version of DCAT, 1.0 vs 1.1 etc.
Jaroslav_Pullmann: (to Rob) I'm wondering how in the profile def'n and request of having dataset info retrieved according to a particular profile relates to a distribution. Because there's a part of the info already in there.
roba: Generally speaking it is
impossible to fully describe a dataset well enough. Hope we
will make some progress. Generally datasets are described by
what datatype(?) specifications they belong to. Easiest way is
to say that it conforms to a Profile.
... it is seen eg. in CDF world. Vital to know whih profiles
are relevant to understand applicable tooling.
<annette_g___> S/CDF/netCDF/
roba: need to label/tag how a
dataset behaves is generally more useful than providing fine
grained descriptions of all its assets.
... need to be able to make a declaration that a dataset
conforms
Jaroslav_Pullmann: if we are talking about meeting constraints that relates to specific representations, it may better be expressed at the distribution level.
roba: yes, that may be true. Distributions are still aspects of the dataset. If it turns out that the requirement is to declare per-distribution what profile it supports, that meets the UC.
antoine: Q for clarification. Rob, the title of the UC, is a metonym. You mean data represented according to a profile, not the profile itself.
roba: yes. we could refine title.
antoine: Well, I wonder whether
the UC relates to discovery of profiles in the first place.
e.g. I am looking at some data(set), and I get information
about various alternatives (profiles) I can get access to
... could be useful to know that there are relationships at
level of profiles that can guide your discovery.
roba: I think that is correct. I
wonder if the profile that the catalog conforms to might list
the profiles that the datasets conform to. Not sure that there
is any global register of profiles.
... Like any other property of DCAT you want to know what
vocabulary it is bound to, i.e. vocab of supported
profiles.
... profile is just a facet of the catalog dataset which are
bound to a vocabulary.
antoine: yes, probably
Proposal: UC 5 is in scope.
+1
<LuizBonino> +1
<LarsG> +1
<DaveBrowning> +1
<Ine> +1
<annette_g___> +1
<Caroline_> +1
<newton> +1
<Jaroslav_Pullmann> +1
<roba> +1
<alejandra> +1
<PWinstanley> +1
<Thomas> +1
<kcoyle> +1
<antoine> +1
<AndreaPerego> +1
<Makx> +1
<Keith> +1
RESOLUTION: UC5 is in scope.
<dsr> +1
https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID42
kcoyle: I'm putting this out
there to see if anyone beyond libraries has this need. In
library world, within same data format, you may have had data
created using different semantic rules.
... these things determine e.g. how you present titles, whether
it was just as on the book or made up, how you formulate
names
<roba> do guidance rules = profiles (is this the same as UC5?)
kcoyle: super detailed, you need to know which rules were used
(stuff like http://www.aacr2.org/...)
kcoyle: I don't know if this is a
broader need.
... these are not things you can then validate.
<Makx> DCAT-AP guidelines https://joinup.ec.europa.eu/node/148075/
LuizBonino: sometimes in [missed context] you create data according to a specific protocol, could be covered by a profile. Rules/structures to indicate what you used to create your data.
kcoyle: it may make more sense to call it "protocols"
<roba> protocols is overloaded in thos context
DaveBrowning: data standards?
Makx: I wanted to support Karen's
point. Even if the library world is very well organized, ...
even doing DCAT-AP in EUrope, we have this profile described in
text, PDF file, partly also in a SHACL file, ... there are
little things people wonder about e.g. contact info (how do I
"use vcard").
... we are looking at a cascade of the questions that arise
during implementation.
... not just things like ordering of names.
... see URL for the guidelines we have begun, https://joinup.ec.europa.eu/node/148075/
roba: Yes I think this is v
similar to the previous usecase, perhaps expressed in different
terms. These guidance rules or protocols, different words
overlap in scope. Profiles may be partially validatable,
supported by guidance. We see in geospatial domain, the need to
profile in this way.
... Usually combination of docs, tools, cookbooks. Seems
basically the same.
<LarsG> g-
annette_g: What I see in a scientific domain - national lab - we see lots of different ways of saying what a term means. I see a need for this in profiles.
<Zakim> danbri, you wanted to ask about stats
danbri: feels like same things as staticians following protocol rules
PWinstanley: possibly a role for
controlled natural language, e.g. cucumber/gurkin approach -
behaviour driven development
... another aspect: rule-based controlled natural languages,
that people are beginning to put together to compile rule sets
that have a natural language reading
danbri: and to point to, rather than standardize here!
PWinstanley: absolutely. You
might use a CNL (controlled natural language) rather than pages
and pages of prose. Even RelaxNG in an XML world. Or
cucumber/gherkin.
... Other things like regelspraak(?sp) for the expression of
rules in areas of public administration - customs, finance
etc.
... we can earn a lot from that.
<PWinstanley> https://www.brcommunity.com/articles.php?id=b622
alejandra: I was wondering in terms of the guidance rules for libraries, you talk more about how to express the titles, the names etc. Seems like a distinction between rules and representation. In biological domain, there is a distinction between the content you expect, the vocabularies, versus the processes that produced the data - clinical etc.
<PWinstanley> http://www.ejhbaars.nl/
alejandra: when I read it, it seemed more like the reporting guidelines, ... what content you expect to describe for different experiments. Typically word/pdf doc, so not very structured. Different communities have gone further eg. XML Schemas.
<PWinstanley> https://github.com/cucumber/cucumber/wiki/Gherkin
<dsr> n.b. cucumber is a controlled natural language for describing tests for software, see https://cucumber.io/
kcoyle: 2 things here. 1.) is
whether this is about the creation of the profile or the data.
I was intending the latter - creation of the data. Even though
communities vary, I think same thing: what are the protocols
for creating your data. While some might emphasise cardinality,
exact data formats, ... in my mind it is better if you stick to
one thing, not everyone will be able to make the same
distinctions. Considering DCAT and profiles I suspect that
such
... distinctions wouldn't be clearly followed
alejandra: Is this just a link to a doc that describes a protocol?
<roba> object property..
kcoyle: ... or to an identifier that describes that protocol
newton: We have a usecase around
dataset publications online from statistical dept, they have
many terms from stats domain. They want to publish with the
dataset a kind of guidance on how to use those datasets.
... e.g. role of natural language tags. A different kind of
analysis can have a very different (and incorrect) result.
Metadata for this kind of guidance would be very useful.
phila: I'm suprised that this discussion has moved to talking about profiles. I saw it more in terms of provenance (whether described in nat language or PROV).
<AndreaPerego> Just to note that we discussed yesterday about provenance / lineage.
phila: but I agree it is just about the data not the metadata.
<roba> profiles is how data "behaves" - it may possibly declare what you may do (functions)
PROPOSAL: 42 is in scope
<alejandra> +q
<phila> s/score/scope/
<Makx> Yhe use case is explicit : "ules determine choices made in creating the metadata"
<AndreaPerego> And also "how to use the data" is mentioned in one of the use cases discussed yesterday - https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID9
alejandra: can we discuss more details. In terms of UC, ... to me, ... I am not sure if it is the same to point to the protocol. In which case it is closer to provenance.
kcoyle: It would be helpful to me
to get usecases from other communities
... LuizBonino can you provide something?
alejandra: if it is as I understood, related to data standards, maybe it also falls into other UC regarding compliance to standards.
kcoyle: yes, I thought about that --- one difference --- problem that I see ... some compliance is about does it comply to schema vs do the semantics comply
<Makx> @kcoyle, is this relevant for UC42: https://joinup.ec.europa.eu/node/148075/
<phila> danbri: For the original library scenario, is this a very pernickity definition of each term? That might be prov or it might be detailed term def
<phila> kcoyle: It's rules for 2 humans to create consistent data
<Keith> surely the point is that consistent rule-controlled data improves precision and recall in retrieval and interoperability
<phila> kcoyle: It has to do with content, not format
<roba> yep - schema compliance is rarely sufficient - need semantic compliance. Provenance may give clues, but we want a declarative statement of what specific purposes the data is fit for
kcoyle: the fact that it in library world content based doesn't mean it doesn't align to format-based protocols in other environments
annette_g: [missed that, sorry]
kcoyle: if you took a library
catalogue and put it out there to download, it's the data
... e.g. CKAN has a lot of library datasets
... you'd want to say what the rules were e.g. if the german
rules were used the canadian libraries mightn't want it (or
vice-versa).
annette_g: people generating the dataset aren't going to be aware of all the rules...
kcoyle: ... but they will care about whether it meets *their* needs. Discoverability and selection.
LarsG: Common usecases in libraries, ... are those 2 books the same? described with same rules?
<Zakim> phila, you wanted to ask if this is a case for the over-used dcterms:conformsTo?
phila: if it isn't provenance,
maybe it is dc conformsTo? a property that is massively
over-used and ambiguous. But maybe relevant.
... e.g. you could say it conforms to parts of some rule
set
... this is where provenance and profiles overlap
Jaroslav_Pullmann: See also UC43
compliance with standards
... not really the metadata of the dataset description
<antoine> +1 this is about conformance
<AndreaPerego> What about DAQ + DUV?
Caroline_: not a problem having similar usecases
kcoyle: it was added after mine. I suspect it expresses the same thing.
alejandra: that was my q before
<Makx> which one?
<antoine> https://www.w3.org/TR/vocab-dqv/#ExpressConformanceWithStandard
<Caroline_> UC43
AndreaPerego: I have impression
we have issues covering data quality, we could look at dataset
usage vocabulary esp data quality parts
... this is something around fitness for purpose, how to use
the data
<AndreaPerego> DUV: https://www.w3.org/TR/vocab-duv/
antoine: see link https://www.w3.org/TR/vocab-dqv/#ExpressConformanceWithStandard on conformance, as mentioned (I think ) by AndreaPerego
kcoyle: but that is conformance of the datasets' metadata?
AndreaPerego: but not so different? just different subject of a similar statement?
kcoyle: I agree, yes.
AndreaPerego: ... since metadata are data as well
antoine: the dqv pattern can be applied to either
proposal: UC42 is in scope
<LuizBonino> +1
+1
<riccardoAlbertoni_> +1
<Thomas> +1
<roba> +1
<AndreaPerego> +1
<newton> +1
<Caroline_> +1
<LarsG> +1
<PWinstanley> +1
<Makx> +1
<dsr> +1
<Ine> +1
<Keith> +1
<annette_g> +1
<antoine> +1
<DaveBrowning> +1
<alejandra> +1
<Jaroslav_Pullmann> +1
<kcoyle> +1
RESOLUTION: UC 42 is in scope
<phila> ==== LUNCH ====
<roba> i have another meeting at 11 - in 1.5 hours, so will probably drop out
<roba> requirements..
<Makx> sorry missed that first part
<DaveBrowning> scribenick:DaveBrowning
<scribe> scribenick: DaveBrowning
<scribe> chair: Caroline_
<Ine> presenst+
<Caroline_> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID24
Thomas: Summarising - describing geospatial datasets but want them to be open
<LuizBonino> I will have to leave to the airport at 14:50.
Thomas: mapping INSPIRE driven
obligations to DCAT
... can we bring geospatial data into the open world?
Ine: Is work on geoDCAT-AP not enough?
Thomas: Not in our
experience
... want to describe only once and publish in multiple forms
but geoDCAT-AP wasn't deep enough
<Zakim> phila_, you wanted to talk about GeoDCAT and Lieven Raes' work
Thomas: multiple standards bodies (ISO, others)
phila_: Work in OGC that should
be in this space?
... perhaps if they need changes in DCAT then communication
should be fairly straightforward
<Zakim> danbri, you wanted to ask that we collect URLs of all the DCAT-focussed email lists
phila_: though that may not mean they completely align
danbri: shall we collect all the DCA lists?
actions: danbri to pull together a list of all the DCAT-focussed lists
<Makx> @dan I have lots of links
<scribe> ACTION: danbri to pull together a list of all the DCAT-focussed lists [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action04]
<trackbot> Created ACTION-23 - Pull together a list of all the dcat-focussed lists [on Dan Brickley - due 2017-07-25].
<danbri> Makx - can you help us collect up URLs for any DCAT email lists you know about? (it doesn't matter if public or closed so long as we understand who can join and what the focus is).
<Thomas> Scope is that we try to find each other as much as possible and we don't go creating competing standards (because I feel there's a risk of that happening)
proposal: accept ID24 as is
<Makx> dan I ll
<Makx> dan i can give you what i have
<Makx> no sound
<Caroline_> webex should be back now
<danbri> Makx, thanks!
Thomas: Implication of the vote - should not create recommendations that are based only on one strand (e.g. INSPIRE, DCAT) - talk to each other
<danbri> Github or W3C for actions? e.g. https://www.w3.org/2017/dxwg/track/actions/23 or should I echo it into https://github.com/w3c/dxwg/issues
proposal: accept ID24 as is
<Thomas> +1
<Caroline_> +1
<Keith> -1 DCAT and INSPIRE are for very different purposes and there are convertors via DCAT-AP
<danbri> +1
<antoine> +1
<Makx> +1
<PWinstanley> +1
<dsr> +1
<LarsG> +1
+1
<kcoyle> 0
<LuizBonino> +1
<Ine> +1
<newton_> +1
<Jaroslav_Pullmann> +1 via additional document
<alejandra> +1
<annette_g> +1 to consider other vocabs but not to try to create a vocab that reflects them all
Keith: INSPIRE and DCAT have different uses/audiences
<riccardoAlbertoni_> 0 (not sure to understand what is wrong with geodcat and I am afraid of duplications..)
Thomas: But people in the field are active in both fields, and mapping between them
phila_: "You cannot make people
use the standard the way you want...."
... if building geo-portal you will follow ISO, if more general
than DCAT
... Can't make one into the other but equally undesirable to
allow one to damage the other
<Zakim> danbri, you wanted to discuss two IDs (main landing page URL in Web and/or DOIs for those who doi...)
danbri: Different kinds of
diversity - some are more annoying than others.
... some things aren't too damaging
Thomas: perhaps could be covered in a cookbook so that people are aware of the decisions needed
Ine: we're not talking about replacings - but how do we serve all the needs?
<Zakim> LarsG, you wanted to talk about bijections between vocabularies
Ine: multiple groups doing very similar mapping activities - a more 'aware' approach would be beneficial
LarsG: Are the semantics the same? If not then mapping is unreliable...
Thomas: My colleagues use INSPIRE as the 'primary'
Caroline_: Seems we have no consensus
Thomas: Propose that we take the effort to make people aware and start a dialog
kcoyle: What's the action on this group?
<danbri> (is http://lov.okfn.org/dataset/lov/vocabs/dcat any use to show the nearby/related vocabularies?)
kcoyle: Would a cookbook approach fulfill what the UC says?
tks AndreaPerego
<danbri> antoine, I was just noting that they've tried to show some basic relations amongst vocabularies. I think it shows only subtype/subproperty etc declarations within schemas/ontologies, rather than co-occurrence in instance data.
antoine: suggestion to avoid divergent effort [Apols - missed the detail]
Makx: community experts best to
write the cookbook relevant to there community
... (schema.org perhaps a special case)
<riccardoAlbertoni_> +1 to Makx
<Zakim> phila, you wanted to talk about a cookbook
<antoine> danbri: yes this goes in the right direction. What we would need is something for profiles. A profile can be made without creating a new ontology so it would be currently missed by LOV
<danbri> Makx, re SDMX, I'd hope this group could make a cookbook for datacube/dcat happen (similarly csvw)
<danbri> ...maybe with collaborations
<Caroline_> +1 to phila about the note
<Thomas> danbri http://lov.okfn.org/dataset/lov/vocabs/dcat might be; I'm personally disappointed that INSPIRE eg isn't linked to DCAT within LOV...
phila: Group planned on geo, joint standards meeting on geo. DXWG remit includes cookbok/guidance - something like liknksets for machines/human interpretation would be well received
RESOLUTION: ID24 not in scope
<Makx> @danbri, this group i
Jaroslav_Pullmann: Do we publish a note?
<Makx> @danbri, this group will not be able to write sdmx mappings, ever
phila: We can publish any guidance.... but guidance on multiple linksets
<Makx> not even sure about data cube mapping
phila: would be a good idea if the bandwidth/enthusiasm existed
<danbri> Makx, that's why I said "make ____ happen" rather than "make."; I agree relevant expertise is needed.
<phila> phila: To clarify, I'm saying that the charter foresees the possibility of the WG creating some sort of primer/cookbook, if it has the capacity to do so. *Separately*, I think a doc on how to publish linksests/mappings would be a very good thing for this WG to do, again, if it has the capacity.
PWinstanley: re: cookbooks/notes - never really completed. Good idea to make a start with this - some kind of skeleton to provide framework - contextualised with the rest of our work
antoine: summarises europeana
effort aggregating existing vocabularies
... two flavours of EDM - internal & external
... others doing similar work eg US Digital Public library,
with some reuse of EDM, some extensions
... UC looks for guidance that what's happening here is being
done appropriately, also on publication, profile
selection
... both for europeana users and by Europeana when ingesting
other info
phila: this seems very close to what the charter requires
kcoyle: Does this imply nested profiles?
antoine: Yes - performing arts area is doing exactly this
LuizBonino: this nesting is something we envisage needing
<AndreaPerego> About nested profiles, you could do that in SHACL.
<riccardoAlbertoni_> interesting something like tracking the profile composition
Makx: DCAT-AP has this with European profile vs national variants/extensions
<LuizBonino> Maybe SHACL could be used to validate entries against the profiles
Makx: Also now looking across such extensions for common extensions not in the base
<Zakim> LarsG, you wanted to ask about modularity
LarsG: we do see vocabularies being used inside DCAT that would be candidates for modular 'insertions'
annette_g: Need to ensure that profiles remain focussed on the solid needs, and not go off building general/abstract profiles chains
<Zakim> danbri, you wanted to ask whether, when foo extends bar, we mean "foo is stricter and more exclusive than bar" or vice-versa.
<alejandra> +q
danbri: We should avoid building formal algebra of profiles (role for machines) rather than substantive focus
antoine: Agree with danbri
<danbri> maybe https://en.wikipedia.org/wiki/Composition_over_inheritance is another way to couch the issues?
antoine: relationship between profiles needs to be more flexible/fluid
dsr: More like delegation of responsibilities
<Zakim> phila, you wanted to talk about conflict resolution in ODRL
phila: ODRL has inheritance but answer is prohibit/allowed with default if indeterminate
<dsr> a question of use cases for knowing details about profiles in DCAT. A clean model would only require the minimum information for handing over to the profile which would be responsible for handling any sub-profiles.
phila: in this space we would
need some conflict resolution
... we'd have to prove it....
alejandra: in most cases profiles would just be 'leaves' - but looking across profiles is still a need
<danbri> (recording a related if old technology: http://www.rddl.org/ was a design for xml namespaces that made a simple HTML page - a bit like a 'profile' - with pointers to machine formats like DTDs, XSDs etc.)
kcoyle: Do profile definers find that they are re-using existing elements or extending.
<Caroline_> s/ \/
phila: U \ack maxually e.g
cardinality
... but profiles stand on their own. (and should stay like
that)
Makx: DCAT-AP is standalone, uses
DCAT and others, adds rules for cardinality etc
... so profile complete in itself
proposed: Accept ID37 as is
<Makx> maybe needs to be revised
<Keith> +q
antoine: UC is not meant to require inheritance
<Zakim> LarsG, you wanted to ask about DCAT-AP vs GeoDCAT-AP
LarsG: what is relation between geoDCAT-AP & DCAT-AP?
<danbri> see also OWL/SHACL representation of DCAT-AP, https://joinup.ec.europa.eu/community/semic/news/call-public-review-owl/shacl-expressions-dcat-ap
<danbri> .... the SHACL seems now to be at https://github.com/SEMICeu/dcat-ap_shacl/tree/master/shacl-latest and is broken into 3 files w.r.t. modularity.
Makx: geoDCAT-AP is DCAT-AP + additional details for geo. No new properties - a separate guideline
Keith: What new requirement in ID37
AndreaPerego: geoDCAT-AP is as
makx said.
... no new mandatory terms & vocabs - reuse what
pre-existed. Additional terms all optional
Makx: Guideline on DCAT-AP includes instructions on extensions - e.g. cant change mandatory to optional
<alejandra> Maxk - have you got a link for those guidelines please?
proposed: Accept ID37 as is
<annette_g> -1
<Makx> put in in several time already
<Thomas> -1
<kcoyle> -.02
<Keith> -1
<LuizBonino> -1
<danbri> +3.02
<Makx> Am technologically challenged now, will send later
<Caroline_> +0
<Ine> 0
<PWinstanley> -0
<Makx> +1
<danbri> -4
0
<LarsG> 0
<Jaroslav_Pullmann> -1, put into separate document?
<AndreaPerego> alejandra, about DCAT-AP extension guidelines: https://joinup.ec.europa.eu/node/150345/
<danbri> (It feels like case-study / blog post territory)
<alejandra> thank you AndreaPerego
PWinstanley: It would benefit from breaking it up
<Makx> i agree with antoine
<newton> scribe: newton
<phila> scribenick: newton
<phila> scribe: Newton
Caroline_: suggest to discuss about UC37 in a next call
<alejandra> +1 for github issues
<danbri> (could we decide issue tracking? otherwise people don't leave the meeting loaded with issues assigned to them...)
<danbri> +1 for github issues
+1 github issues
<PWinstanley> +1 for github
Keith: is leaving for a meeting. he thanks for all the fishes.
<AndreaPerego> RDA - https://www.rd-alliance.org/
danbri: asks about the preference about github issues or w3c issues
<Zakim> danbri, you wanted to ask if anyone here would prefer to use W3C's Issue Tracker in preference to Github?
<riccardoAlbertoni_> I would prefer to use the W3c which tracks conversations in the mailing list ...
AndreaPerego: w3c issue tracker can be integrated to the mailing list
<alejandra> +1
<danbri> PROPOSAL: We use Github for tracking issues.
<Thomas> +1
+1
<AndreaPerego> +0
<Caroline_> 0
<LarsG> +1
<annette_g> +1
<antoine> 0
<PWinstanley> +1
<riccardoAlbertoni_> 0
<danbri> +1
<Ine> 0
<Jaroslav_Pullmann> +1
<kcoyle> 0
<DaveBrowning> 0
<riccardoAlbertoni_> +1 to vote for the other one
<danbri> Lars asks actions vs issues (w3c vs github)
LarsG: asks if we will use w3c for actions and gh for issues
<AndreaPerego> DXWG GH repo - https://github.com/w3c/dxwg
Caroline_: some of the members are not used to github, so the group will help
<danbri> riccardoAlbertoni - can you clarify?
<danbri> or are you ok with Github for issues?
riccardoAlbertoni_: the w3c issue tracker is very useful
<danbri> W3C has some basic support materials for Github https://www.w3.org/2006/tools/wiki/Github#Using_issues
riccardoAlbertoni_: it was useful for tracking discussions about the issues
Caroline_: anyone else wants to
comment or can we have a resolution?
... asks danbri to explain the advantages of using github issue
tracker
<LarsG> scribe: newton
<LarsG> scribeNick: newton
danbri: the downside is the lack
of integration with w3c tools
... you can create tags to classify issues
kcoyle: when creates an issue on github you receive an email?
dsr: yes
... dealing with issues on github is easy
... you can write using markdown syntax
<scribe> ACTION: dsr to check if it's possible to give the power of creating issue to every member of github repository [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action05]
<trackbot> Created ACTION-24 - Check if it's possible to give the power of creating issue to every member of github repository [on Dave Raggett - due 2017-07-25].
<antoine> https://github.com/w3c/dxwg/issues
antoine: I used both
systems
... asks if there's notification by email on the list if
someone comments on the issue
Caroline_: let's decide to use github then
RESOLUTION: We use Github for tracking issues.
Caroline_: it's necessary to raise the issue about last discussion
<scribe> ACTION: kcoyle to create issue on github about the discussions on ID37 [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action06]
<trackbot> Created ACTION-25 - Create issue on github about the discussions on id37 [on Karen Coyle - due 2017-07-25].
alejandra: similar to uc42
... this is also related to validation, but there is another
use case for that
Caroline_: anyone else thinks there's a big difference and wants to mention
PROPOSED: UC43 is in the scope
<annette_g> +1
<Caroline_> +1
<alejandra> +1
+1
<antoine> +1
<danbri> +1
<LarsG> +1
<Jaroslav_Pullmann> +1
<PWinstanley> +1
<dsr> +1
<AndreaPerego> +1
<Thomas> +1
<Ine> +1
<kcoyle> +1
RESOLUTION: UC43 is in the scope
<DaveBrowning> +1
UC: UC44
Jaroslav_Pullmann: based on the
discussion about citing data or reference to subset of
data
... suggest the need to linking to particular version of a
distribution
... dereferencing the distribution
phila: are you talking about splitting dataset into chunks?
Jaroslav_Pullmann: not necessary
<phila> DWBP's comments on subsets
Jaroslav_Pullmann: about linking to particular version of the subsets
phila: there's a BP related to this
<Caroline_> /w3c.github.io/dwbp/bp.html#dataVersioning BP 7/ http://w3c.github.io/dwbp/bp.html#dataVersioning Best Practice 7: Provide a version indicator//w3c.github.io/dwbp/bp.html#dataVersioning BP 7
phila: it's not a good idea when using query strings
Jaroslav_Pullmann: we discussed
yesterday if an API can retrieve a subset of the dataset
... and having an URI to that subset
phila: it's not so good to use URI based on query string, because you may eventually change your system and it may break
<AndreaPerego> This means it is strictly relying on persistent URIs.
annette_g: there are two
questions: one about versioning
... another about subsets
Jaroslav_Pullmann: maybe the subset could be considered a new dataset not a version
alejandra: what's the difference between identifying a dataset or a subset of it?
<phila> phila: Identifiers don't have semantics!!!
Jaroslav_Pullmann: when you're
citing a dataset you may want to reference to a specific part
of the dataset
... because a dataset is abstract
... what happens if you want to cite concrete data, data within
the distribution
alejandra: suggest to rephrase
UC44
... the identifier is different from the downloadURL
<Zakim> danbri, you wanted to say we might try to have PROV folk do this (by recording workflow log of transformations such as subsetting/slicing)
Jaroslav_Pullmann: if it's in scope should be an action to rephrase it
Caroline_: suggests to keep the discussion on the mailing list
<Zakim> AndreaPerego, you wanted to note that how this can be done is very much domain specific
<danbri> (there's looking inside a dataset/distrib to understand what's in there; there's slicing out chunks of it by some facet/param or identifier; and there's identifiers for all aspects of this)
AndreaPerego: it's specific for a
particular domain
... maybe there's not a solution that covers all domains
Jaroslav_Pullmann: asks for a possible general solution
AndreaPerego: the discussion is
similar to that we had yesterday about the data service
... want to discuss more of this on the mailing list
<alejandra> dcat:Distribution does not have and identifier, so +1 for adding that if the UC points to that
Jaroslav_Pullmann: for purpose of citation how to make URI of distribution resolvable and access concrete parts of a dataset
<scribe> ACTION: Jaroslav_Pullmann to update UC 44 and share in the mailing list [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action07]
<trackbot> Created ACTION-26 - Update uc 44 and share in the mailing list [on Jaroslav Pullmann - due 2017-07-25].
<Jaroslav_Pullmann> ACTION: update description of UC ID44 and post to the list for further discussion [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action08]
<trackbot> Error finding 'update'. You can review and register nicknames at <https://www.w3.org/2017/dxwg/track/users>.
<AndreaPerego> s/by,/bye,/
Caroline_: we will discuss about
conneg and in the last 30 minutes we will discuss about the
next steps
... we'll stop now and get back at 3:50 PM
bye antoine!
<Caroline_> -----break until 3:50 pm------
<phila> scribe: PhilA
<scribe> scribeNick: phila
kcoyle: We have 5 use cases to try and get through in in hour
<danbri> https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#ID2
RubenVerborgh: UC2 is saying that
a dataset might be available in multiple ways, this is what I
have available
... The server can say what it has available, and the client
can say what it prefers
ac, a
<Zakim> AndreaPerego, you wanted to just comment on an issue with citing distributions
LarsG: I think it's relevant
Jaroslav_Pullmann: We should align this with, for example, Rob's use case, indicating availability of profiles
<RubenVerborgh> Which IDs are these?
phila: See ID 5 RubenVerborgh
[May have missed a bit of what Jaroslav_Pullmann said]
Jaroslav_Pullmann: I'd just make
a note - it would be good to specify the relation to other use
cases that look at profile nego
... the title is a bit misleading if it's only about media
type
RubenVerborgh: That makes sense. ID5 is related, as is 30
<scribe> ACTION: ruben to make links between ID2, 5 and 30 [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action09]
<trackbot> Created ACTION-27 - Make links between id2, 5 and 30 [on Ruben Verborgh - due 2017-07-25].
Ine: Is the media type part of the profile?
RubenVerborgh: media types of profiles are orthogonal to what the profile says
Ine: I'm confused by the title cf. the problem statement and requirements
RubenVerborgh: Yes, I should
clean that up.
... For conneg purposes, the profile can be in any
serialisation.
... Idea is that it will work with whatever you define
Ine: I think you need to make clear which media type is available
RubenVerborgh: Yes.
... If you look at HTTP, you already have conneg by media
types
<Zakim> LarsG, you wanted to make a suggestion for change of title
LarsG: I think I understand what
Ine meant about the title of the use case. Maybe we just talk
about semantic interpretation
... I think we should either talk about media type or content
type, not both
RubenVerborgh: Yep, I agree
<Zakim> RubenVerborgh, you wanted to comment on profiles and media types
<LarsG> +1 to RubenVerborgh
RubenVerborgh: AFAIC, there will be a generic mechanism for expressing profiles, not media-type specific
AndreaPerego: Is it worth
clarifying the notion of a profile?
... I have a use case similar to this one. You can use @rel
profile, but this can be used to tell you what is used, it
can't be used for conneg.
PROPOSED: Accept ID2, modulo revising the title, linking to related use cases, disambiguate the word profile
<Thomas> +1
<RubenVerborgh> +1
<dsr> +1
<riccardoAlbertoni_> +1
<alejandra> +1
<annette_g> +1
<Jaroslav_Pullmann> +1
+1
<Ine> +1
<newton> +1
<Caroline_> +1
<LarsG> +1
<DaveBrowning> +1
RESOLUTION: Accept ID2, modulo revising the title, linking to related use cases, disambiguate the word profile
<AndreaPerego> +1
<danbri> -1
<Makx> 0
<AndreaPerego> About the "profile" link relationship type: https://tools.ietf.org/html/rfc6906
<Makx> 0 because i came in late and haven't followed
danbri: Do it anyway but...
There's a core idea that makes sense, distinguishing more than
media type allows
... I don't think conneg has never succeeded well on the
web
... For some reason, the idea of a client saying "I like A, B
and c" has captured the imagination of the Sem Web
... But it hasn't caught on elsewhere
... It makes fingerprinting easy, since you give more
info
... Google is always asking for all the URLs we should be
indexing
... What do we do here? Ask for all the versions?
<danbri> +1
<PWinstanley> +!
<PWinstanley> +1
danbri: I'm supportive of the idea, but it's not something that search crawlers are going to do
<Zakim> RubenVerborgh, you wanted to answer DAn
RubenVerborgh: I understand Dan's point, but the use cases doesn't mention the mechanism
<danbri> (my prediction re search engines ... it's hard enough to talk re Google, and I can't speak for Bing/Yandex/Yahoo/etc.)
RubenVerborgh: This is purely about the use case, doesn't mentionion content negotiation
<danbri> (the UC mentions https://ruben.verborgh.org/articles/fine-grained-content-negotiation/ which does)
<dsr> so this is about best practices for linking to specific formats, e.g. via link relations in HTML rather than relying on HTTP content negotiation which can cause problems for finger printing and for search engines
<danbri> dsr, yes imo
RubenVerborgh: ID3 builds on 2 and asks for server-side implementation
PWinstanley: Does this relate to
what we talked about previously wrt inheritance mechanism for
bringing profiles together?
... If so, we have to be able to join them at the hip
<RubenVerborgh> Actually, what I said was: ID3 builds on ID2 by supporting the notion that response can confirm to multiple profiles.
phila: I don't think it does
Jaroslav_Pullmann: I'm asking
myself how this relates to multi-part messages
... What use would clinents make of such a complex
response?
... A multi-part message has a reasonable detail of how to
reassemble
RubenVerborgh: A response might
include multiple profiles
... Profiles are not necessarily orthogonal to each other
Jaroslav_Pullmann: Would it be a statement about how individual profiles relate to each other?
<danbri> RubenVerborgh, does this UC relate to https://w3ctag.github.io/packaging-on-the-web/#downloading-data-for-local-processing?
RubenVerborgh: No need for
multiple parts, can be a dingle response that conforms to
multiple profiles
... If the client has a list of vocabs it understands, I can
say, do you have a dataset expressed in these vocabs?
Jaroslav_Pullmann: It sounds to me a little ... I'm trying to imagine the client. This is technically interesting but I'm looking at the pragmatics
RubenVerborgh: Few RDF datasets use a single vocabulary, they commonly use more than one.
LarsG: I think we need to
consider this outside the world of RDF.
... There are notions of profiles of XHTML etc
... We have blocks of HTML with different info in them
Jaroslav_Pullmann: But then we have a similar root element. That's missing here
LarsG: It can have, but doesn't have to, which makes it more generic
Jaroslav_Pullmann: There's no sequencing, so you can't see which response is for which profile
annette_g: I may not be understanding the concept but it seems one would create a single profile that covers all the vocabs used
<Zakim> RubenVerborgh, you wanted to talk about "simply create a profile"
RubenVerborgh: because it doesn't
scale
... You'd have to make a profile for every combination
annette_g: Example please?
<danbri> I'm not quite hearing a case of it not scaling
RubenVerborgh: provides one but ...
annette_g: What domain would that happen, if you're publishing a coherent dataset, you should be able to publish a coherent profile
RubenVerborgh: If everyone publishes their own profile, then we have too many, if they're small they're more reusable
Jaroslav_Pullmann: I can only imagine this working if we stick to RDF that has its own integration
<danbri> last hour of a 2-day meeting ... brains might be sagging
Jaroslav_Pullmann: I can't see how other sorts of resources would be integrated
<Zakim> phila, you wanted to talk about inheritance
<alejandra> phila: we were talking about this before, and even though we didn't get to a resolution
<alejandra> ... there was kind of agreement that we will have one profile
RubenVerborgh: If we have just one profile, then the problem is how to relate then
<alejandra> phila: I don't think we will have such a profusion
<alejandra> ... we will get a small number of well-known profiles
<Zakim> LarsG, you wanted to talk about modular profiles (again)
<alejandra> phila: ... fewer profiles with any number of vocabularies
<danbri> sorry, https://github.com/SEMICeu/dcat-ap_shacl/tree/master/shacl-latest is url
LarsG: Coming back to my earlier
point - profiles might be modular
... It would be interesting to say "OK, use that profile, but
where people are described, they're done like this"
... So I end up saying this UC is in scope
<Zakim> danbri, you wanted to ask whether this might be a matter for shacl/shex modularity e.g.
<RubenVerborgh> My fear is then that profiles will be an underspecification, just like MIME types are at the moment. I.e., the dataset will conform to more than it explicitly indicates, so there still will be a difference between "profile X from provider A" and "profile X from provider B"
<RubenVerborgh> so +1 to modularity for me
danbri: I'm fine with the use
case, but I suspect the ShEx/SHACL will be at a lower
level
... I see that DCAT-AP is defined in 3 separate SHACL files
<alejandra> https://github.com/SEMICeu/dcat-ap_shacl/tree/master/shacl-latest
kcoyle: You're saying you might share socially and then put into a SHACL file [Not sure that's accurate recording]
<AndreaPerego> @danbri, there'll be other ones for GeoDCAT-AP and StatDCAT-AP
<danbri> phila, I suspect the modularity will be at the shex/shacl lower level (since those languages have explicit re-use systems already designed)
Keith: I wonder whether this use case is a Research Object - combinations of data, software, documentation etc
<danbri> AndreaPerego, cool!
Keith: It's a bundle of useful stuff - and I wonder if this use case is getting at that from a different angle
Makx: Ruben's explanation of
clients going around is unclear to me. But as Lars says, I like
modular approach, building your profile from different
parts
... How you do that in SHACL or whatever, then that's for
later
<RubenVerborgh> I can rewrite ID3 to focus on modularity, as there seems to be interest in that.
Makx: What people do is publish data and they publish it in a specific style
<alejandra> +1 to Makx
Makx: They don't publish in
multiple profiles
... But I like the idea of reusable profiles but I don't think
that's what Ruben is saying here
RubenVerborgh: I agree with Makx. I'm happy to write the UC in that direction
<Makx> good ruben
kcoyle: So shall we ask Ruben to revise the UC and bring it back?
<alejandra> +q
annette_g: Just to remind us of
the previous conversation about modularity - it allows change
within a module independent of the thing using it. But you're
not going to want changes in one module to ripple through
without control
... So I am hesitant about inheritance
alejandra: If you want a
description of a person, you're likely to want the same things,
so having a small library of profiles sounds useful
... And I think most people will agree on what those profiles
would look like
... As long as you have the same mandatory elements then you
can add what you want without necessarily implying
inheritance
annette_g: I see a distinction
between doing that at the DCAT level and the profile
level.
... Different research groups provide data in different ways
and the interpretation is domain-specific
... Trying to use modularity in a way that one module could be
changed and thereby change your profile, wouldn't be
acceptable
kcoyle: We've had this discussion
twice now
... Can we resolve that UC3 needs carefully rewriting by Ruben
et al?
<scribe> ACTION: ruben to rewrite UC3 to take into account discussion at Day 2 of the Oxford F2F meeting [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action10]
<trackbot> Created ACTION-28 - Rewrite uc3 to take into account discussion at day 2 of the oxford f2f meeting [on Ruben Verborgh - due 2017-07-25].
<AndreaPerego> I think Stephen Richard's UCs have been contributed by SimonCox
AndreaPerego: I think we have 2 use cases rom Stephen Richard, contributed by Simon Cox
phila: The issue described by the
charter
... It's useful to have the extra support from outwith the
group
AndreaPerego: This is about
negotiating the data profile - the distribution
... It's not about the metadata
RubenVerborgh: I don't think we
can do more until we know more. It hints at some
solutions
... I don't see it clearly enough to vote.
Jaroslav_Pullmann: I agree this
needs a bit of reworking
... It might just need a more detailed description of the
distribution
kcoyle: Why don't we leave the 2 that are Richard's and move on to Andrea's UC30?
AndreaPerego: This is related to
some of the issues alreay raised by Ruben and Lars
... The use case is reporting what the European data Portal
does - harvesting across portals and converting to
DCAT-AP
... We have standard catalogue services able, like Catalogue
Service from OGC and OAI-PMH
... In OAI-PMH you can say what profile you want
... These interfaces are not compatible as they have different
parameters
... So the Requirement is to have a standardised mechanism to
get metadata in a given format and schema
... HTTP conneg is a possible solution
... In GeoDCAT-AP we tried to surface the ability to provide
data in that within a Catalogue Service
... This info is included in the HTML representation
... It's reflecting some of the requirements already presented
by Ruben but in a specific application we're facing at the
moment.
RubenVerborgh: 3 things to
mention. 1 it seems similar so maybe it can be merged with UC2.
2. I think this UC is phrased more in terms of the solution
while we need to just look at hte problem for now.
... 3 It might make sense to keep it separate if we focus on
the harvesting part as that is not mentioned elsewhere.
kcoyle: At other times, we have
said we're not too bothered by duplicate use cases, we'll
de-dupe at the point of requirements.
... If you feel we haven't covered harvesting enough then we
can have a separate use case.
RubenVerborgh: For me it's the same. WDYT Andrea?
AndreaPerego: I think although we have the same requirements, the starting point is quite different. I agree with Karen that we shouldn't merge use cases unnecessarily, just the reqs
<danbri> "harvesting" can mean quite different things to different audiences (eg. global web crawlers vs dedicated dataset aggregators)
<Zakim> RubenVerborgh, you wanted to propose merging with UC2 and to
AndreaPerego: For the harvesting bit, OK
<riccardoAlbertoni_> I don't see any harm in listing the existing solutions assuming that the use cases are for requirements and not for suggesting solutions, and we will be to adopt or find a new solution when we will discuss how to address the requirements
AndreaPerego: The intention is
not to say that this is the solution, just to take into
account, we need to be careful if asking for disruptive changes
in the existing landscape
... we can't ask people to change their infrastructure
... Need to find least-disruptive solution
... So this solution here is less impactful, just enable
conneg, which is already available.
... But I can try to rephrase it
kcoyle: Can we vote on whether we consider this to be in scope
PROPOSED: Accept UC30 as being in scope
<annette_g> +1
<riccardoAlbertoni_> +1
<Thomas> +1
<newton> +1
<RubenVerborgh> +1, I'd just suggest to slightly rephrase the title
<Caroline_> +1
<Ine> +1
<Jaroslav_Pullmann> +1
<PWinstanley> +1
<alejandra> +1
<LarsG> +1
<Makx> +1
<DaveBrowning> +1
<Keith> +1
RESOLUTION: Accept UC30 as being in scope
<dsr> +1
<AndreaPerego> Agreed.
<danbri> +⅔
<Makx> hurray
kcoyle: We have gone through the
use cases!
... With only a few deferred.
kcoyle: We have, I hope, made
progress to help the UC editors
... The UCs aren't yet complete can go in as a draft
Jaroslav_Pullmann: I can go
through the meeting notes and work on that
... We'll create a template and use that
... Describes being able to filter datasets by licence
... I suggest leave the tags in place so only relevant UCs can
be shown through some sort of JS switching
kcoyle: So on the homepage of the WG, we have a list of the key dates that came out of a W3C doc showing deadlines for requesting transitions
<AndreaPerego> s/some some sort/some sort/
kcoyle: August 9th and Nov 1.
Between those two, we can produce a document, but we don't
before then there will be a gap before we can publish
... We're aiming for First Public Working Draft. It's a draft
that the WG is sufficient to give people an idea of where we
are.
Jaroslav_Pullmann: I'm on leave at the beginning of August. I'll support Rob and Ixchel
kcoyle: The next task is getting our subgroups going
AndreaPerego: Just to mention an
approach used by the Spatial Data WG at the end. They used
sprint releases, unofficial targets/deadlines
... This might be useful
<Zakim> AndreaPerego, you wanted to mention the "sprint" mechanisms used for SDWBP
kcoyle: I believe we can do as many drafts as we find useful
Caroline_: It's not clear to me what those dates are?
kcoyle: It's if we don't get it done by 9 August there'll be a gap.
phila: They're 'Publishing Moratoria' - when the webmaster isn't available
kcoyle: The first thing we need is whether this gives you enough to begin
PWinstanley: I think, yes. We
have worked out what we want to do. Mostly architectural. There
are dependencies - mostly from the agreed list of
requirements
... so that our sections point to agreed requirements
kcoyle: It seems that the UC group can pull out the reqs
PWinstanley: We've started that from what's in the wiki
<scribe> ACTION: dsr to ask Ivan Herman about script to help link UCs and Reqs [recorded in http://www.w3.org/2017/07/18-dxwg-minutes.html#action11]
<trackbot> Created ACTION-29 - Ask ivan herman about script to help link ucs and reqs [on Dave Raggett - due 2017-07-25].
PWinstanley: We need to be more
specific about terminology, esp RFC2119 keywords
... Once it's version controlled, we can make links
Caroline_: I've started pulling out the Reqs from the UCs on the wiki
kcoyle: I believe Rob said he'd
look at profiles
... At this stage in the day, I think we should bring it up at
the next call
... There hasn't been any activity on that yet.
... I think we need to get that started ready for the push-pull
between DCAT and profiles
Jaroslav_Pullmann: For structuring the use cases, I think we have a stable template
<Zakim> phila, you wanted to talk about smarts
<riccardoAlbertoni_> +1 to have requirements referenced in the uc so that you have not to rewrite and you can reference to them also in future ..
phila: See, for example, https://www.w3.org/TR/dwbp-ucr/, https://www.w3.org/TR/sdw-ucr/, Jaroslav_Pullmann
dsr: It might be appropriate to
think about call timing, give geographical spread
... Also other ways of working, maybe Google Docs, distributed
meetings
kcoyle: And one hour is not a great deal
<Jaroslav_Pullmann> fine, thanks for the examples, Phil
kcoyle: We're trying to add a reporting back session in each call
Makx: We talk about sub groups but I'm not aware of where they meet, etc.
<Zakim> Makx, you wanted to ask about subgroup logistics and dates
kcoyle: We only have the use case group active so far
<danbri> is the teleconf time 14:00 UTC mondays? I see that in the last call agenda but not in https://www.w3.org/2017/dxwg/wiki/Meetings#Teleconference_Agendas_and_minutes
kcoyle: We encourage those groups to use the main mailing list with a [topic] in the subject line
Makx: Do we expect work to start in August?
<AndreaPerego> In SDW, for subgroups we had an IRC channel and WebEx
kcoyle: As an American I never stop
Caroline_: It's winter
now..
... We were talking about process with Alejandra...
... The idea is to have everything on the mailing list
... Also would be nice if the editors got together, make that
public, and when you have the call, use the IRC, take minutes
etc.
kcoyle: if we use IRC off meeting times, does RRS Agent work
dsr: Another thing - think about messaging - at some point we'll want to think about what we want to say. Do we want a single pager, speaking points? Press release?
PWinstanley: Apart from Europe,
who else is interested in DCAT? Public catalogues etc.
... Much of our discussion tends to look at academic worlds. If
we get administrations, we can get the bodies that they
fund.
dsr: These are the sort of
questions you need to address before the outreach
... It might be useful to have a short white paper describing
who would use the tech
... We have a comms team who can help
danbri: I'd like to be counted as part of that.
<Zakim> LarsG, you wanted to talk about Chile
LarsG: I've seen interesting work done on legislation data in Chile
PWinstanley: That's important to have those people onboard if poss
danbri: from Google - we have a dozen conversations with early adopters, bioschemas etc.
<Makx> legislation -> look at ELI
danbri: We're pluralistic about what we'll index - what's there basically.
PWinstanley: We can hook it into
things like the Share-PSI BPs
... So those who have had that on their radar can see what's
happened next
... All EC states have their guidance docs that can be
updated
<Thomas> European Legislation Identifier LarsG
<Makx> http://eur-lex.europa.eu/eli-register/about.html
PWinstanley: We don't want people to take years to get up to speed because they haven't heard about it.
kcoyle: We should decide very shortly that we're done
[None]
kcoyle: meeting adjourned
<danbri> There is also http://www.godan.info/ for agricultural data (and a strong developing world component)
<danbri> thanks all!
<AndreaPerego> Thanks, and bye!
kcoyle: Thanks everyone!
LarsG: Thanks the chairs
<Makx> kudos to kcoyle
<AndreaPerego> +1
RESOLUTION: Thanks to Alejandra for hosting!
<newton> +1
<riccardoAlbertoni_> +1
<danbri> +1
<AndreaPerego> +1
<annette_g> +1
<kcoyle> +1
<Caroline_> +1
<Ine> +1
<alejandra> :-)
+1
<dsr> +1
<LarsG> +1
<PWinstanley> +1
We gratefully acknowledge funding for lunch and coffee breaks from the VRE4EIC project.