| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | AE | AF | AG | AH | AI | AJ | AK | AL | AM | AN | AO | AP | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | This document is open to edit by anyone. It is shared publicly via the website. | Person 1 | Person 2 | Person 3 | Person 4 | Person 5 | Person 6 | Person 7 | Person 8 | Person 9 | Person 10 | Person 11 | Person 12 | Person 13 | Enter your responses below | Enter your responses below | Enter your responses below | Enter your responses below | Enter your responses below | Enter your responses below | |||||||||||||||||||||||
2 | Type | Attribute | Description of Attribute | Current Categorisation | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | What is your considered category? | Reason why? | |
3 | EXAMPLE | Title | This is an example attribute | MUST | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | SHOULD | Reasons why it should/ should not be here/somewhere else | |
4 | CORE | Identifier | An unambiguous reference to the resource within a given context. | MAY | MUST | It would be unthinkable not to have this! Surely dData is almost useless after prototyping stage without proof of source and version... | MUST | Essential to ensure unique identifaction and citation | MUST | A URI is required if the dataset is going to be joined into a knowledge graph | MUST | Possibly the most important field in this list! We can't have a meaningful conversation about the world if we can't agree on how to identify all the things in the world :) | MAY | MUST | Unique identifier useful where names are similar for multiple items | MUST | MUST | None of this works without stable identifiers | MUST | to make sure data is linkable and reusable | SHOULD | This is important to make sure people do not confuse the dataset with others. DOIs are good because weblinks can break or be changed. | MUST | to make sure data is linkable and reusable | SHOULD | This is important to make sure people do not confuse the dataset with others. DOIs are good because weblinks can break or be changed. | MUST | An unabiguous identifier is not only helpful for a dataset, but also for a version within a dataset. This could be covered by a update to the version - but for ease of linking - an unambiguous link is great (see Zenodo for good practice on this - i.e. provides a doi to the version, but also a separate doi to the latest version of a dataset | |||||||||||||||
5 | CORE | Title | A name given to the resource. Typically, a Title will be a name by which the resource is formally known. | MUST | MUST | MUST | More human friendly! Helps differentiate between similiar data sets | MUST | MUST | MUST | MUST | MUST | MUST | MUST | MUST | MUST | SHOULD | The Title of the dataset might change over time, so some flexibility here might help (as the unambiguous link above should provide the link) | |||||||||||||||||||||||||
6 | CORE | Description | This is a free text description of the data set. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. | MUST | MUST | MUST | Help people decide whether it is the right one before downloading /applying to use it | MUST | SHOULD | MAY | If the dataset is simple enough, and the title is clear enough, additional description should not be required. | MUST | MUST | MUST | MUST | MUST | MUST | MUST | |||||||||||||||||||||||||
7 | CORE | Creator | An entity responsible for making the resource. | MUST | MUST | MUST | Part of the quality assessment of potential reusers | SHOULD | SHOULD | MUST | MUST | MUST | MUST | but this may not be easy | MUST | MUST | but this may not be easy | MUST | SHOULD | always helpful to have some information here, wondering if shoud be optional, so that it does not preclude orgainsations or people from publishing data | |||||||||||||||||||||||
8 | CORE | Publisher | This is the entity responsible for making the data set available. | MUST | MUST | MUST | Part of the quality assessment of potential reusers | MUST | SHOULD | MAY | If Creator == Publisher then one could be omitted to simplify. | MUST | MUST | SHOULD | if there is a clear publisher | MUST | SHOULD | if there is a clear publisher | MUST | SHOULD | always helpful to have some information here, wondering if shoud be optional, so that it does not preclude orgainsations or people from publishing data | ||||||||||||||||||||||
9 | CORE | Language | A language of the resource. | MAY | SHOULD | SHOULD | May be difficult retrospectively, but it is good practice and would help with accessibility | MAY | MAY | MAY | SHOULD | SHOULD | SHOULD | SHOULD | It is helpful but presumably most UK energy data is going to be in English anyway? | SHOULD | SHOULD | It is helpful but presumably most UK energy data is going to be in English anyway? | MAY | ||||||||||||||||||||||||
10 | CORE | Contact Point | Relevant contact information for the cataloged resource. Use of vCard is recommended [VCARD-RDF]. | SHOULD | SHOULD | Wouldn't necessarily say vCard is the best standard - but not overly fussed. Are vCards not a Microsoft thing? I don't use them so not sure. | SHOULD | Would need to ensure it is easy to amend this as it will change over time! | SHOULD | SHOULD | MAY | Lots of cases where this might not be available. | MUST | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | better practice for orgainsations could be a contact that is generic - that could be rereouted as staff change | |||||||||||||||||||||||
11 | TOPICAL | Keyword | A keyword or tag describing the resource. | MUST | MUST | MUST | Need to be clear what the difference between this & keyword | SHOULD | MUST | MUST | Ideally with some kind of protection to prevent typos or case differences creating additonal tags. | SHOULD | Highly desirable | SHOULD | Fine with making this mandatory, but this is a term which allows multiple values in DCAT and can therefore be satisfied with an empty list, is this what you intend? | SHOULD | if full text search is also available, key words may be optional. | SHOULD | Keywords should adhere to a standard vocabulary. | SHOULD | if full text search is also available, key words may be optional. | SHOULD | Keywords should adhere to a standard vocabulary. | ||||||||||||||||||||
12 | TOPICAL | Subject | A topic of the resource. | MAY | MAY | MAY | Need to be clear what the difference between this & keyword | MAY | If there is a pre-specified list of topics then I'd upgrade this to a SHOULD | SHOULD | Agree with Ayrton: It'd be useful to use a controlled vocab for common 'subjects' like 'solar power timeseries' | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | |||||||||||||||||||||||||
13 | PROVENANCE & LINEAGE | Provenance | A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation. | SHOULD | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | SHOULD | Very important but may be difficult to do retrospectively, would be MUST for new data | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | good to know the history of the data | SHOULD | SHOULD | good to know the history of the data | SHOULD | ||||||||||||||||||||||||
14 | PROVENANCE & LINEAGE | Was generated by | An activity that generated, or provides the business context for, the creation of the dataset. | SHOULD | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | SHOULD | See note above | SHOULD | SHOULD | Should also express whether the data comes from real physical metering, or simulation, or surveys, etc. | MAY | Freeform? This could become so broad as to be useless. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | ||||||||||||||||||||||||
15 | PROVENANCE & LINEAGE | Is Version of | A related resource of which the described resource is a version, edition, or adaptation. | SHOULD | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | SHOULD | MAY | If you only have one version of the resource should you still create an `is version of`attribute for that dataset? | SHOULD | SHOULD | MAY | MAY | SHOULD | if version is not managed properly, it may cause confusion. | MUST | Makes clear if it is an updated version of a series of data. | SHOULD | if version is not managed properly, it may cause confusion. | MUST | Makes clear if it is an updated version of a series of data. | ||||||||||||||||||||||
16 | PROVENANCE & LINEAGE | Version | The version number of a resource. | SHOULD | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | MUST | Important for identification of what you have and for things like data citation and FAIR data | SHOULD | SHOULD | MAY | Only useful if a form is given. SemVer? | MUST | MUST | SHOULD | Consider specifying further (i.e. requiring semantic versioning) but also allow for cases where the resource is dynamic and versioning is not meaningul | SHOULD | MUST | Helps to know the previous versions. | SHOULD | MUST | Helps to know the previous versions. | MUST | ||||||||||||||||||||
17 | PROVENANCE & LINEAGE | Version Notes | A description of changes between this version and the previous version of the resource. | MAY | SHOULD | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | SHOULD | Need to know what has changed, especially for new data | MAY | SHOULD | SHOULD | MUST | MUST | SHOULD | SHOULD | SHOULD | SHOULD | MAY | if any substantive change - if not - a presumption that it is similar data but more of it | ||||||||||||||||||||||||
18 | PROVENANCE & LINEAGE | Previous Version | The previous version of a resource in a lineage. | MAY | SHOULD | Without provenance, data is not provably true. Any random data could be added without any indication of where it comes from. | MAY | SHOULD | SHOULD | MAY | SHOULD | SHOULD | SHOULD | good to have some version history records | SHOULD | SHOULD | good to have some version history records | SHOULD | MAY | ||||||||||||||||||||||||
19 | PROVENANCE & LINEAGE | Is Replaced By | A related resource that supplants, displaces, or supersedes the described resource. | MAY | MUST | The amount of time wasted by not knowing a dataset is superceded is highly problematic. Acknowledge this is difficult to achieve. | MUST | MAY | MAY | SHOULD | Should if versioning at all. | MAY | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | MAY | |||||||||||||||||||||||||
20 | PROVENANCE & LINEAGE | Was derived from | A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity. | MAY | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | SHOULD | Should be known as part of the process, so for new data this should be there | SHOULD | Will require N:1 mappings | MAY | Could get messy when a dataset is derived from many datasets | MAY | MAY | MAY | SHOULD | MAY | SHOULD | MAY | ||||||||||||||||||||||||
21 | TEMPORAL | Temporal Coverage | Temporal characteristics of the resource. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | Must if temporally bounded. | MAY | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | needs to have information on what the timestamp relates to (end of period, start of period, mid period) and operational data needs to be in ISO 8601 | |||||||||||||||||||||||||
22 | TEMPORAL | Date Created | Date of creation of the resource. | MUST | MUST | MUST | MUST | MUST | MUST | If a fixed dataset (e.g. document). Not relevant if a stream. | MUST | MUST | SHOULD | Resource creation time is tricky for some kinds of resource, I'd rather see this as 'SHOULD' in cases where it's applicable rather than forcing providers to populate a field with ambiguous semantics | MUST | MUST | MUST | MUST | |||||||||||||||||||||||||
23 | TEMPORAL | Date Modified | Most recent date on which the catalog entry was changed, updated or modified. Publish date according to ISO8601 standard. | SHOULD | MUST | Without provenance and or date, data is not provably true. Any random data could be added without any indication of where it comes from. | MUST | Need to understand what you are looking at especially if the versioning isn't very informative | MUST | SHOULD | MUST | Ditto | MUST | MUST | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | ||||||||||||||||||||||||
24 | TEMPORAL | Accrual Periodicity | The frequency with which items are added to a collection. | MAY | SHOULD | Critical quality inidicator | MAY | SHOULD | SHOULD | MAY | SHOULD | SHOULD | MAY | SHOULD | It helps to know how often a resource is updated or re-released. | MAY | SHOULD | It helps to know how often a resource is updated or re-released. | |||||||||||||||||||||||||
25 | TEMPORAL | Date issued | Date of formal issuance (e.g., publication) of the item. Publish date according to ISO8601 standard. | MUST | MUST | MUST | SHOULD | MUST | MAY | Not relevant to a stream. So context-dependent MUST. | MUST | MUST | SHOULD | Similar to 'Date Created', there are kinds of data resources which don't fall into this model | SHOULD | MUST | SHOULD | MUST | |||||||||||||||||||||||||
26 | TEMPORAL | Temporal Resolution | Minimum time period resolvable in the dataset. This is intended to provide a summary indication of the temporal resolution of the data distribution as a single value. | MAY | MAY | MAY | SHOULD | SHOULD | MUST | Must if temporally divided - again contextual. | MAY | MAY | MAY | SHOULD | It is very helpful to quickly know the granularity of time series data, particularly for the monitoring of networks (hourly, half-hourly etc.). | MAY | SHOULD | It is very helpful to quickly know the granularity of time series data, particularly for the monitoring of networks (hourly, half-hourly etc.). | |||||||||||||||||||||||||
27 | TEMPORAL | Date Valid | Date and often a date range of validity of a resource. Publish date according to ISO8601 standard. | SHOULD | SHOULD | SHOULD | MAY | MAY | SHOULD | SHOULD | SHOULD | SHOULD | but it may be difficult to maintain, and keep it up-to-date | SHOULD | SHOULD | but it may be difficult to maintain, and keep it up-to-date | SHOULD | ||||||||||||||||||||||||||
28 | FORMAT & SCHEMA | Format | Describe the file format, physical medium, or dimensions of the resource. | MUST | MUST | MUST | MUST | MAY | MUST | Format(s) plural if this is an API - would expect content negotiation to provide, e.g., JSON, XML, potentially CSV, depending on the client request. | MUST | MUST | SHOULD | This doesn't feel like something that should be mandated. A lot of these terms only really apply to resources which have a 'downloadable' nature | MUST | MUST | MUST | MUST | |||||||||||||||||||||||||
29 | FORMAT & SCHEMA | Conforms To | An established standard to which the described resource conforms. | MAY | SHOULD | Critical quality inidicator | MAY | SHOULD | SHOULD | MAY | Must if it does conform. | MAY | MAY | MAY | SHOULD | Is helpful to know what kind of standards the data conforms to, such as ISO8601 for time series. | MAY | SHOULD | Is helpful to know what kind of standards the data conforms to, such as ISO8601 for time series. | ||||||||||||||||||||||||
30 | LICENSING & RIGHTS | License | A legal document giving official permission to do something with the resource. | SHOULD | MUST | No licence means the data is, essentially, useless for any commercial use. | SHOULD | This may be difficult retrospectively but all new datasets MUST have one! | MUST | MUST | Use SPDX License identifier | SHOULD | SHOULD | SHOULD | MUST | Ambiguous licensing precludes almost all potential use of a data set | MUST | This is a must, otherwise, people don't know what they are allowed to do | SHOULD | MUST | This is a must, otherwise, people don't know what they are allowed to do | SHOULD | |||||||||||||||||||||
31 | LICENSING & RIGHTS | Rights | Information about rights held in and over the resource. | SHOULD | MUST | No licence means the data is, essentially, useless for any commercial use. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | MUST | SHOULD | MUST | SHOULD | ||||||||||||||||||||||||||||
32 | SPATIAL | Spatial Coverage | Spatial characteristics of the resource. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | Must if this is relevant. Spatial dataset without these characteristics of limited discovery value. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | |||||||||||||||||||||||||||
33 | SPATIAL | Spatial Resolution In Meters | Minimum spatial separation resolvable in a dataset, measured in meters. | MAY | MAY | MAY | SHOULD | SHOULD | Few energy datasets are dense, gridded datasets (that is, few energy datasets are on a regular geospatial grid.). Instead, resolution in terms of whether the data is from individual energy resources, or spatially aggregated in some way, would be useful | MAY | MAY | MAY | MAY | not necessarily in meter, can be in other measures (eg. address level, postcode level, LSOA level) | SHOULD | Can include other geographies like postcode level, LSOA level etc. | MAY | not necessarily in meter, can be in other measures (eg. address level, postcode level, LSOA level) | SHOULD | Can include other geographies like postcode level, LSOA level etc. | |||||||||||||||||||||||
34 | SPATIAL | Geometry | Associates any resource with the corresponding geometry. The locn:Geometry class provides the means to identify a location as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system. | MAY | MAY | MAY | MAY | MAY | MAY | MAY | MAY | MAY | good to have | MAY | MAY | good to have | MAY | ||||||||||||||||||||||||||
35 | SPATIAL | Is defined by [UK Administrative Regions, Postcodes etc] | rdfs:isDefinedBy is an instance of rdf:Property that is used to indicate a resource defining the subject resource. This property may be used to indicate an RDF vocabulary in which a resource is described. | MAY | MAY | MAY | MAY | MAY | MAY | MAY | SHOULD | MAY | SHOULD | MAY | |||||||||||||||||||||||||||||
36 | QUALITY | Quality annotation | Represents quality annotations, including ratings, quality certificates or feedback that can be associated to datasets or distributions. Quality annotations must have one oa:motivatedBy statement with an instance of oa:Motivation (and skos:Concept) that reflects a quality assessment purpose. We define this instance as dqv:qualityAssessment. | MAY | SHOULD | If quality data is the key aim of this project. Perhaps insisting that this is addressed is important? | MAY | I don't like the term "quality" as this is very subjective - I would personally call it "additional information" as it is also less emotive! People aren't always willing to identify known issues if it is perceived in a negative light! | SHOULD | Even a short description of issues in the dataset can save a lot of work, ideally there should be a standard template for describing these issues | MAY | I continue to be nervous about single "scores" for quality for energy datasets. Dataset A might be awesome for use-case 1, but awful for use-case 2. There's no single quality metric that satisfies all possible use-cases. | MAY | MAY | MAY | MAY | MAY | MAY | MAY | ||||||||||||||||||||||||
37 | ACCESS | Access URL | A URL of the resource that gives access to a distribution of the dataset. E.g. landing page, feed, SPARQL endpoint. | MUST | MUST | MUST | MUST | MUST | This could also be a public cloud bucket URL, e.g. "gs://nowcasting-data" for Google Cloud | MUST | MUST | MUST | SHOULD | This may either not exist or may be provided directly rather than by external reference. It should probably be a requirement to do either a reference or inline definition, but requiring an access URL as an item in of itself may not always be appropriate | SHOULD | if there is such url | MUST | SHOULD | if there is such url | MUST | MUST | ||||||||||||||||||||||
38 | ACCESS | Download URL | The URL of the downloadable file in a given format. E.g. CSV file or RDF file. The format is indicated by the distribution’s dcterms”format and/or dcat:mediaType. | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | SHOULD | MAY | SHOULD | SHOULD | MUST | Helps get the download and improves user experience if the link is not immediately obvious from the access url. | SHOULD | MUST | Helps get the download and improves user experience if the link is not immediately obvious from the access url. | ||||||||||||||||||||||||||
39 | HAVE ANY MORE? ADD THEM BELOW | ||||||||||||||||||||||||||||||||||||||||||
40 | Type of dataset | Timeseries? Map? Survey of regulations? List of energy assets? (suggested by Jack) | Agree strongly | Agee - controlled vocab needed for interoperability | SHOULD | Would be useful to have classes of dataset, e.g. tabular/API | should | Agree. | Agree. | agree | |||||||||||||||||||||||||||||||||
41 | Energy resource | Solar / wind / CCGT / etc. (suggested by Jack) | Agree strongly | HOw is this different from Subject/Keyword? | SHOULD | perhaps simplest to link on fuel rather than technology | should | Aren't these covered by Subject? | agree | ||||||||||||||||||||||||||||||||||
42 | Which physical quantities does this dataset record? | Power? Temperature? etc. | Agree strongly | May be more difficult to know, or may be very complicated to explain | SHOULD | Already a lot of existing work here from the OEO based on the UNITs ontology | |||||||||||||||||||||||||||||||||||||
43 | Units | kW? Kelvin? Volts? | agree | ||||||||||||||||||||||||||||||||||||||||
44 | Cost of the dataset | Conditions for the dataset is free/ free at the point of use; and other situations that data need to be paid to use | Agree strongly | Agree | Covered by licensing? | Should | But probably will be covered in the landing page of the dataset/ licencing. | Agree strongly. Sometimes this is hard to find out. | Should | But probably will be covered in the landing page of the dataset/ licencing. | Agree strongly. Sometimes this is hard to find out. | ||||||||||||||||||||||||||||||||
45 | Linked/reference dataset | related dataset that will likely to be needed when interpreting the focusing dataset | So like calibration datasets? | Should | Should | ||||||||||||||||||||||||||||||||||||||
46 | Size on disk | The size of the dataset (after compression), e.g. in GBytes | Agree | agree | SHOULD | Agree | Agree | ||||||||||||||||||||||||||||||||||||
47 | Size (before compression) | For dense N-dimensional arrays, give the size of each dimension. e.g. number of rows | Agree | ||||||||||||||||||||||||||||||||||||||||
48 | Historical dataset? Or continually updated? Or both | Maybe should have two metadata entries: one for the historical dataset; another for the live data | Agree | There are lots of differences in metadata requirement from timeseries (continuous) and one off data sets,but this distinction be covered under the type description? | would agree this could be a helpful way of splitting datasets into some that are updated on regular basis (perhaps with changes in historical data) and those that are snapshots - i.e. may contain errors that are subsequently updated by the ongoing updated data) | ||||||||||||||||||||||||||||||||||||||
49 | Number of energy assets described by the dataset | 1 solar system? 1,000,000 solar systems?! | |||||||||||||||||||||||||||||||||||||||||
50 | Naming convention for energy assets | MPAN? REPD? | Agree | ||||||||||||||||||||||||||||||||||||||||
51 | Any privacy concerns related to dataset | e.g. very specific locational data | Or whether there is any sort of Ethics process? I suppose perhaps the Access area could have some metadata field about whether it is open or if there is a process to follow? With this as controlled vocab | ||||||||||||||||||||||||||||||||||||||||
52 | Data processing | Is this raw data? Or aggregated in some way? Or cleaned? Can we link to the Python script used to process the data? | MAY | ||||||||||||||||||||||||||||||||||||||||
53 | Embargo / (c) expiry? | can (c) data transition to (cc) data after a period N? i.e. after which point in time does the data become CC-BY-4.0 (this would have to be tied to a version) | Agree strongly | Agree | MAY | ||||||||||||||||||||||||||||||||||||||
54 | |||||||||||||||||||||||||||||||||||||||||||
55 | The meaning of each column in the dataset | e.g. "col1 = Power in kW; col2 = UTC timestamp in ISO 8601 format" | Context is so important, but need to be open to how this is achieved | Handled within MEDA by recommending CSVW (JSON-LD representation) | Strongly agree. Units should also be obvious. | Strongly agree. Units should also be obvious. | |||||||||||||||||||||||||||||||||||||
56 | Who funded the collection of the data? | Might already be covered by Creator, but could be good for transparency. | |||||||||||||||||||||||||||||||||||||||||
57 | Could be interesting to have a section on uncertainty | might be covered under the description | |||||||||||||||||||||||||||||||||||||||||
58 | Temporal aggregation | At least "period-ending" or "period-beginning". Even better: "Each row represents the mean of the previous hour of data" | |||||||||||||||||||||||||||||||||||||||||
59 | Meaning of polarity | What does a negative powerflow mean? e.g. -ve means power flowing from grid to building; +ve means power flowing from building to grid | strongly agree | ||||||||||||||||||||||||||||||||||||||||
60 | would be great to also have a below the line comments section for each dataset | provides a community way of allowing issues with the data set to be pointed out | |||||||||||||||||||||||||||||||||||||||||
61 | Value used to identify null data | e.g. "NaN", " ", "?", "-" | Should be able to specify when there are multiple null types, ideally should also be able to describe these at a column level | strongly agree | |||||||||||||||||||||||||||||||||||||||
62 | Access method | How the data is accessible eg by a URL/by following a registration process/not open/it's so big you need to SFTP it! | I think it would be helpful to be clear about how data can be accessed, rather than assuming it will be a URL | ||||||||||||||||||||||||||||||||||||||||
63 | |||||||||||||||||||||||||||||||||||||||||||
64 | |||||||||||||||||||||||||||||||||||||||||||
65 | |||||||||||||||||||||||||||||||||||||||||||
66 | |||||||||||||||||||||||||||||||||||||||||||
67 | |||||||||||||||||||||||||||||||||||||||||||
68 | |||||||||||||||||||||||||||||||||||||||||||
69 | |||||||||||||||||||||||||||||||||||||||||||
70 | |||||||||||||||||||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||||||||||||||||||