Extend schema for data dictionary. about mdjson-schemas HOT 26 CLOSED

I'm wondering about adding a name element to domain. The value may be the
coded value, name will provide the named value corresponding to the code.

On Fri, Nov 7, 2014 at 5:04 PM, stansmith907 [email protected]
wrote:

Here is a first pass at a JSON structure for data dictionary info. The
comment period is open!

{
"version": {
"name": "adiwgJSON",
"version": "0.10.0"
},
"contact": [],
"metadata": {},
"dataDictionary": {
"description": "",
"domain": [
{
"domainId": "",
"name": "",
"description": "",
"member": [
{
"value": "",
"definition": ""
}
]
}
],
"entity": [
{
"entityId": "",
"name": "",
"definition": "",
"primaryKeyAttribute": [""],
"index": [
{
"name": "",
"unique": true,
"attributeName": [""]
}
],
"attribute": [
{
"name": "",
"definition": "",
"dataType": "",
"required": true,
"units": "",
"domainId": "",
"minValue": "",
"maxValue": "",
"foreignKey": {
"entityId": "",
"attributeName": ""
}
}
]
}
]
}
}

—
Reply to this email directly or view it on GitHub
#25.

from mdjson-schemas.

Good suggestion Dennis. The above structure has been updated.

from mdjson-schemas.

Suggestion from Josh to move foreign key from attribute to entity level. The above structure has been updated.

from mdjson-schemas.

Revision to foreignKey attribute names, made foreignKey an array.

from mdjson-schemas.

ISO requires an attribute to have a 'local' or 'common' name (gfc:memberName). But the 'code' name is optional (gfc:code). In our mdJson our "name" element is not specific as to whether it is common or code (we obviously have a common code problem). I assumed when we wrote mdJson name was used as 'code' which is more likely to be the name observed at the top of a spreadsheet column or in a SQL dump. Should we clarify this and allow elements for both? If we do, which are required? Common name to match ISO standards or code name to match physical data? or both?

This naming issues also applies to entities as well. In addition, ISO allows entities to have aliases. I'm not suggesting we support aliases, just tossing it out there in case someone else sees the need..

from mdjson-schemas.

More items from ISO. If we want to support building 19110 records we may need a few more fields in our mdJson.
For the dataDictionary we on have "description", other elements needed/possible are:

• name
• scope
• version
• version date
• language
• responsible party

All but language are required for 19110. So see any reason NOT to add them?

from mdjson-schemas.

What about using a citation block for those additional fields? It covers all but language and resourceType. That also would allow use of onlineResource to link to other representations of the dd.

from mdjson-schemas.

I edited my previous comment: responsible party should have been resourceType

from mdjson-schemas.

Close. In other situations we have resourceType immediately preceding citation so that would work fine. Language is optional in ISO so we could language outside citation or drop it. My concerns are that citation does not have a description and presentationForm is not the same as scope. Identifier and onlineResource do not need to be in the JSON. So, I'm not comfortable that citation is close enough.

from mdjson-schemas.

FYI, in 19115-1 data dictionary will need to be an array. We can set the mdJson to accommodate that now but -2 can have only one dictionary in a 19110 file. Thoughts?

from mdjson-schemas.

I thought we were using resourceType = scope in ISO? Any we could move the
desciption and language properties to the root. I think it would be useful
to allow onlineResource in the json - it would be handy to link to
supplemental or other(richer) representations of the dd.

On Friday, November 21, 2014, stansmith907 [email protected] wrote:

Close. In other situations we have resourceType immediately preceding
citation so that would work fine. Language is optional in ISO so we could
language outside citation or drop it. My concerns are that citation does
not have a description and presentationForm is not the same as scope.
Identifier and onlineResource do not need to be in the JSON. So, I'm not
comfortable that citation is close enough.

—
Reply to this email directly or view it on GitHub
#25 (comment).

===============
Joshua Bradley
Arctic LCC Data Manager
U.S. Fish and Wildlife Service
101 12th Avenue, Room 110
Fairbanks, Alaska 99701
907.455.1847 (ph)
http://arcticlcc.org
===============

from mdjson-schemas.

We are. So better stated: identifier, onlineResource, and presentationForm would be suppressed and resourceType, definition, and language would be outside citation. Citation would only support name. version, versionDate, and responsibleParty. Is that enough, or is that a stretch to use it here?

from mdjson-schemas.

And found another entity attribute required for ISO (gfc:isAbstract) - is the entity abstract? I have modified the template at top.

from mdjson-schemas.

Updated mdJson with citation for dataDictionary. Place citation and several other information fields in a dictionaryInfo block.

from mdjson-schemas.

I made another change to the above dataDictionary object. responsibleParty in citation should have been an array.

from mdjson-schemas.

And I made another change to the above dataDictionary object. changed entity>index>unique = 'true' to allowDuplicates = 'false'. I think the meaning is a bit more clear.

from mdjson-schemas.

Should language be an array?

from mdjson-schemas.

Suggest using description instead of definition for entity and attribute.

from mdjson-schemas.

Should commonName be required for domain?

from mdjson-schemas.

Is attribute>required supposed to indicate whether null values are allowed? If that's the case, I think changing to something like allowNull would be better.

from mdjson-schemas.

'required' changed to 'allowNull' in reader and writer. Completed.

'commonName' required has not effect on reader or writer. 19110 does not carry information about the domain, only the domain values.

from mdjson-schemas.

Implemented in v0.9.3 and latest viewer build.

Still need descriptions and translations for each property.

from mdjson-schemas.

We have a problem. I have 'dataDictionary' at same level as 'metadata' and you have 'dataDictionary' as an element of 'metadata'.

from mdjson-schemas.

We have a problem. I have 'dataDictionary' at same level as 'metadata' and you have 'dataDictionary' as an element of 'metadata'.

Fixed by c8d1939. Moved dataDictionary to the root. Probably should've bumped the version to 0.10, but I figured we'd need to move to 1.0 soon anyway.

from mdjson-schemas.

If you decided to publish your data dictionary in multiple languages, then
you would have a repeated dictionary instance for each language. I don't
see any practical use of expressing a dictionary in part one language and
part another. I think the dictionary should conform to one language.

On Wed, Dec 3, 2014 at 12:34 PM, Josh Bradley [email protected]
wrote:

Should language be an array?

—
Reply to this email directly or view it on GitHub
#25 (comment).

from mdjson-schemas.

Implemented.

from mdjson-schemas.