Publish a vocabulary/ontology at a stable URL

[MarinaNitze]

For "pod" namespace, once final 1.0 schema proposed in #44 is accepted:

pod:systemOfRecords
pod:webService
pod:accessLevel
pod:accessLevelComment
pod:primaryITInvestmentUII
pod:bureauCode
pod:programOffice
pod:dataQuality

Based on #44, am I missing anything?

[haleyvandyck]

Now that #44 is merged and we have a v1.0 schema, would love to get this vocabulary/ontology published. Any additional changes before doing so? cc: @MarinaMartin @gbinal

[jpmckinney]

Also add pod:dataDictionary

[gbinal]

For bureauCode and programOffice:

I've created simpler, easier to use versions in csv and json. Results are in this branch, right now just as CSV and JSON files in the assets folder and as parenthetical links on the schema page.

I'm not sure of a good way to address the others but any thoughts on integrating these?

@seanherron and @benbalter, I was modifying your earlier work. Any thoughts?

[haleyvandyck]

I think that sounds great @gbinal, thanks for your help with that.

@MarinaMartin do you have more thoughts on the "pod" namespace issue?

[benbalter]

the "pod" namespace issue?

Huh? If I'm following correctly, this namespaces all the field names? If this would affect the JSON or other machine readable versions that would presumably be API'd I'd be 👎. Don't normally see namespacing within an API in non-government contexts, unless I'm misreading?

For bureauCode and programOffice:

Can we use something more universal/useful/descriptive than "POD-formatted code"? 1. It's an abbreviation, 2. it's purpose built, 3. If it's just a concatenation of two fields, do we need to duplicate the data? Diffs would be less clean and would need to maintain information twice.

[jpmckinney]

@benbalter Nearly all properties (fields) are already namespaced, since they are based on DCAT, Dublin Core, etc. which are all namespaced. What the project has done so far is to simply drop the namespace when building JSON and CSV files, and I anticipate that it will continue to do so. The namespace is only used in the RDF representations, which is exactly what's expected.

POD uses some properties that have no RDF term. This issue is simply to create those missing RDF terms, and the namespace for those terms will be "pod". An RDF term like "dcterms:language" is actually a CURIE (Compact URI), which expands to http://purl.org/dc/terms/language, because in RDF all properties have URLs. "pod" would similarly expand to a URL, where the POD-specific terms (those that don't come from DCAT, etc.) will be defined.

TLDR: This issue will end up filling in all the empty RDFa values in these tables.

@gbinal's commits seem to be unrelated to this issue.

[MarionRoyal]

We can offer vocab.data.gov for the URL base for this concept if needed.

Marion A. Royal
202.302.4634

Sent from PDA

On Dec 4, 2013, at 6:50 PM, James McKinney notifications@github.com wrote:

@benbalter https://github.com/benbalter Nearly all properties (fields)
are already namespaced in RDF, since they are based on DCAT, Dublin Core,
etc. POD uses some properties that have no RDF term. This issue is simply
to create those missing RDF terms, and the namespace for those terms will
be "pod". An RDF term like "dcterms:language" is actually a CURIE (Compact
URI), which expands to http://purl.org/dc/terms/language, because in RDF
all properties have URLs. "pod" would similarly expand to a URL, where the
POD-specific terms (those that don't come from DCAT, etc.) will be defined.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/136#issuecomment-29858460
.

[mhogeweg]

if POD defines new terms not covered in existing vocabularies like DC, ISO, RDF, ... then yes, these terms should be assigned a stable namespace and like DC, the expanded URI would ideally be de-referencable (you can look them up).

In addition to the definition of terms, I'd also define value domains where possible to avoid that these fields become free text fields (bureauCode for example).

[rebeccawilliams]

Flagging that this was addressed in Defining the JSON-LD context and use of associated JSON-LD keywords. Should anything be added here @philipashlock?

[gbinal]

I think we're good and this issue can be closed.