[Application-profiles-ig] Encapsulation

[Karen Coyle]

Thanks, Nishad. Some comments interleaved: On 8/21/19 5:32 PM, Nishad TR wrote: >The current three-layer hierarchy can be useful in various use-cases, in>which application profile can be a hackable 'concept' for representing>metadata. A flat list of statements can be assumed that they belong to a>simple and/or single default description. In that way, all>'statements,' if explicitly not declared under any other 'description'>belongs to the 'main.'>>Sone imaginary use-case concepts are,>In a collection of multiple CSV files, separate CSV can be expressed in>an independent description.I have thought only vaguely about how one would deal with, for example, a separate CSV for each description. That's a discussion I would find very interesting. >Descriptions can be reused as classes (?).The reuse of descriptions, I think, depends on the schema. The question is whether the "attributes" of the description are integral to it. If we aren't thinking in terms of RDF, then a description in most schemas cannot be separated from the statements. For example: description:book777 { statement:creator123 property: dct:creator type: xsd:literal minoccur: 0 maxoccur: 3 statement:title787 property: dct:title type: xsd:literal minoccur: 1 maxoccur: 1 value: "Here's the title" } If, in some way, you refer to the thing identified as "book777" what exactly are you addressing? I assume that you are addressing the entirety of the data within the brackets. that may not be what you meant. ? Logically I can see how in an RDF scenario there would need to be a class "description" and a class "statement". Also, without some statement of type (description v. statement) it may not be possible to know which you have if we do not require that each profile have the three levels of hierarchy: description set, description, statement. This is where being open to a very loose set of requirements can cause problems in data interpretation. If we have: abc: label: "anything" minoccur: 2 Is that a description or a statement? It would be best not to have to guess, because the guess could be wrong. I'm thinking we need something like: abc: type: description label: "anything" minoccur: 2 that "type: description" could work as a class statement, couldn't it? If this is what you mean, then I think we need to add a type property (that may not be the best name) for each "thing" in the vocabulary. >In a single CSV (or any other data source), some values can be reused(or>mixed and matched) into virtual containers. And such virtual containers>can be mapped to descriptions.That is essentially what I mean with encapsulation: can we (easily) have a schema that allows the creation of these types of containers and mapping? At what points in our schema can such a container be employed? What attributes need to be "outside" the container so that this can be done, and how easy and logical will it be for creators? >>Moreover, multiple layer of structure also permits to record multiple>layers of 'meta-metadata.'>>Another question, can we use nested descriptions, or simply is it>possible to use descriptions inside descriptions ?BIG question that we haven't currently addressed. I'll tell you my gut feeling which is that initially we should offer a very simple schema that has only the three levels, and get that working in some user-friendly profile creation software. The we should try to employ nesting and see what the issues might be. It may actually be easier to implement nesting in a schema than it is to make it easily usable for profile creators. Whew! That's a lot of questions, sorry, but I don't have a picture in my head of what a profile will be beyond the simplest version. Let's at least create that simple version and see if we can make it work for the simplest cases. kc >>Nishad>>>On August 22, 2019 at 9:08:27, Karen Coyle (kcoyle at kcoyle.net>< mailto:kcoyle at kcoyle.net>) wrote:>>>With a design that has only a limited structure with only descriptions>>(也可以认为是实体)和声明s (that can be thought>>of as attributes of the entities) we won't facilitate true encapsulation>>of data, and therefore we don't facilitate a great deal of reuse. Any>>differences in how the descriptions and statements are defined will>>require the creation of new, individual descriptions and statements.>>That means that elements like labels and cardinality will define the>>描述或声明一样s the identifier. We're back to the>>pre-E-R or O-O world where data records contained awkward repetition>>because of a lack of modularity.>>>>I suspect that if we are keeping profiles simple then the trade-off will>>be that simplicity means less modularity. If you see any way around>>this, or think that my analysis is flawed, please speak up!>>>>kc>>>>-->>Karen Coyle>>kcoyle at kcoyle.nethttp://kcoyle.net>>skype: kcoylenet-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet