Hi, Mariana - thanks for giving it a read. Comments below.
On 1/22/18 2:14 AM, Mariana Curado Malta wrote:
> Hi Karen,
> This is interesting.
> I have the following considerations:
> 1. The "proposed ontology" - why do you call it an ontology ?
I'm not particular on what it is called. Vocabulary is fine, too.
> I can see that it is a descriptive metadata application profile (MAP) -
> or upper MAP, that is, it describes a MAP for a specific context (as far
> as I can see a MAP is a data model with declaration of RDF
> vocabulary terms and its constraints). So it is another level of MAP
> that defines how to describe a MAP. Should we call it an ontology or
> should we set a specific name for this "kind" of MAPs? - you called it
> DSP, actually, but I think we should be carreful on how we call things
> and specially try to stick to the same names, just giving descriptive
> variation names.
This is meta, which is tricky. The idea was to develop terms to describe
profiles. I was generally following the DSP structure  but did not
want to mint new properties where there were ones I thought I could use.
The result is that this ends up being a profile for profiles. And I
wonder if there still needs to be a truly meta vocabulary for profiles.
> 2. The "diagram for the vocabulary" - what vocabulary? The ontology?
> Why to you use a relational model, with keys, and foreign keys? I would
> do a conceptual model in a UML class diagram since it is more clean and
> less "tableitis" .
This is because of the intention to make use of the work of the tabular
data W3C working group. Although tables are perhaps not the ideal
technology, the fact is that many application profiles use tables or
some tabular form (e.g. in spreadsheets and even Word documents). The
tabular data group has developed code that transforms the tables of
instance data into either RDF or JSON. That code needs foreign keys.
Your statement below about URIs and IDKeys is exactly where I started
and this may be why a more "meta" model would be needed. Perhaps I need
to name this something more like "tabular profile vocabulary" and have
that be a profile of a more general profile. Do you think that removing
the foreign keys would be sufficient to create that general profile?
that would not be difficult, and adding in the foreign keys for the
tabular data profile would then be simple.
> We guys from the software engineer background suffer a lot of tableitis
> and it is something that we need to be cured of!
> Each IDKey is an URI, and the foreign key will be a property (if needed
> - probably not - with the range being the entity from where the
> foreignKey comes from). Each line with an arrow is another property with
> the range to the other entity. I don't really think you should introduce
> this entropy in the diagram.
> 3. SchemaList.csv
> How do you describe "Description", "Statement", "Datatype value",
> "Literal value" and "Object value"? - that is, the entities of your
> relational model?
Yes, I do need to go back and create a column for definitions. Note that
although I used "description set" "description" and "statement" from the
DSP, I must say that I like the terms used in the BIBFRAME profiles. 
> I don't know if what I say makes sense to you.
It absolutely does. And thanks.
> Thank you and regards, Mariana
>  http://geverest.umn.edu/home/papers-and-publications/-tableitis
> POLITÉCNICO DO PORTO. INSTITUTO SUPERIOR DE CONTABILIDADE E
> ADMINISTRAÇÃO DO PORTO
> POLYTECHNIC OF PORTO. PORTO ACCOUNTING AND BUSINESS SCHOOL
> Mariana Curado Malta
> Professora Adjunta. Senior Lecturer
> Rua Jaime Lopes Amorim, s/n. 4465-004 S. Mamede de Infesta. PORTUGAL
> T +351 22 905 00 XX F +351 22 902 58 99
> [log in to unmask]
> CEOS.PP <https://www.iscap.ipp.pt/investigacao-1/centros/ceos/ceos>
> Research Center
> Researcher ID: http://www.researcherid.com/rid/D-8627-2014
> *De:* DCMI Architecture Forum <[log in to unmask]> em nome
> de Karen Coyle <[log in to unmask]>
> *Enviado:* 21 de janeiro de 2018 18:39:47
> *Para:* [log in to unmask]
> *Assunto:* [RDF AP] First draft Tabular Metadata Profiles
> It's been a while since we had the DCMI RDF AP group active, and I feel
> that we took a bit of a detour due to the W3C work on RDF validation.
> However, I remain interested in finding a truly "core" solution for the
> many small and not-so-small developers who are working with metadata and
> need some direction for the formulation of useful profiles.
> I have been working with a small group of folks to develop a viable
> method for creating simple profiles in a tabular form. The work so far
> is on my github site. The home page there includes a short
> explanation of the goals of the project. Files highlighted on that page
> include a statement of requirements , and a proposed
> ontology/vocabulary . There is also a diagram giving a picture of the
> area covered by the vocabulary . Finally, there is a tabular
> comparison of this vocabulary, the DSP vocabulary, and the vocabulary of
> BIBFRAME profiles .
> I consider this a beginning, with nothing set in stone at this point,
> and appreciate all comments, questions, suggestions, corrections, and of
> course offers to participate in making this work.
> Thank you,
>  https://github.com/kcoyle/RDF-AP/
>  https://github.com/kcoyle/RDF-AP/blob/master/requirements.md
>  https://github.com/kcoyle/RDF-AP/blob/master/schemaList.csv
>  https://github.com/kcoyle/RDF-AP/blob/master/dspDiagram2.jpg
>  https://github.com/kcoyle/RDF-AP/blob/master/BIBFRAMEcompare.csv
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234 (Signal)