Where to store the prefix definitions

kcoyle commented 3 years ago

We threw out some ideas about where to store prefix definitions. We seem to have agreed that they would be in a separate file, but can we define a rule so that separate file is standardized and easy to address?

kcoyle commented 3 years ago

(1): Prefix definitions are assumed to be taken from prefix.cc unless stated otherwise

This puts a burden on the consuming application to determine if prefixes have been defined, so it doesn't change the effort much.

kcoyle commented 3 years ago

(2) Prefixes are stored in separate files in the same directory as the template

This requires a naming convention for the prefix files. Can we develop a naming convention that is sufficiently multi-language friendly?

kcoyle commented 3 years ago

(3) Prefix files are given identifiers and are reusable

It isn't clear in this option what will connect the prefix file and the profile.

tombaker commented 3 years ago

How about:

There are many ways to associate prefixes with namespaces: JSON-LD contexts, Web resources such as prefix.cc, files stored either in the same directory as a profile or in a file somewhere else on the Web that is addressable by its URL. This Simple Model makes no assumptions about where prefixes are defined. Programs designed to convert CSV into other profile languages, such as ShEx or SHACL, will need to support whatever methods are used in a particular context. A note about the method used can be recorded in the annotation column.

philbarker commented 3 years ago

Not sure if we have an issue for it, but we did discuss the potential need for some metadata about the application profile itself (e.g information about date, creator, license... YAMA has some minimum requirements that are a good start). The location of prefixes is one of the things that could be included with this metadata (OK, it's more like manifest information than metadata, but I don't think that worries me.)

kcoyle commented 3 years ago

Yes, we are assuming that some PROV-like info may be desired. As I recall we figured that we wouldn't define elements for this but could point to some existing vocabularies if people want to use them. (This could go in the user documentation, but not in the vocabulary documentation.) From Phil's comment here I am taking away that we also need to indicate or advise on where such information should reside. If we don't, it is possible that some people will enter it into the profile itself, which would not be the best solution.

tombaker commented 3 years ago

@philbarker I agree that we should have something to say about minimal metadata about the profile itself and agree that this could be a good place to indicate where the prefixes are located.

@kcoyle I agree that we should discourage putting that metadata in the profile itself. However, the model could allow people to add extra columns (outside of the model) as they see fit. In that case, conversion programs might, by default, support the "standard" model but be easy to tweak to support additional columns.

acka47 commented 3 years ago

Re. adding profile metadata, I took a look at some options, one of them https://csvy.org/. As YAML front matter in csv is not supported by many applications, the approach of describing the profile in a yml file with the same name as the profile csv file makes sense to me:

for backward compatibility you can always add to your data.csv a data.yml metadata file

philbarker commented 3 years ago

W3C CSV on the Web which allows you "to add metadata to describe the contents and structure of comma-separated values (CSV) data files", looks relevant:

it's JSON-LD
uses DCTERMS for general descriptive properties (schema.org and DCAT also options)
allows for metadata about individual columns, which may be we could leverage to map non-standard labels to identifiers we specify for the columns
it's part of set of reports and recommendations around RDF and tabular/ CSV data on the web, which might a direction we want to go in the future
it can be used to define expected types and values for columns

I'm not saying that we want to do all of these things now, nor am I saying that it does everything we might want to so, but I think it might be worth mentioning as an option for implementers.

tombaker commented 3 years ago

@kcoyle I have marked this as "POSTPONED". Do you agree?

kcoyle commented 3 years ago

This is now being discussed at https://github.com/dcmi/dctap/issues/3, which also links back to here.

dcmi / dcap

Where to store the prefix definitions #66