Adding Document Field DP #733
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> | ||
| PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> | ||
| PREFIX cco: <https://www.commoncoreontologies.org/> | ||
| PREFIX obo: <http://purl.obolibrary.org/obo/> | ||
| PREFIX owl: <http://www.w3.org/2002/07/owl#> | ||
|
|
||
| SELECT ?document ?document_field | ||
| WHERE { | ||
| ?document obo:BFO_0000178 ?document_field . #has continuant part | ||
| ?document a cco:ont00001298 . #document | ||
| ?document_field a cco:ont00001243 . #document field | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> | ||
| PREFIX cco: <https://www.commoncoreontologies.org/> | ||
| PREFIX obo: <http://purl.obolibrary.org/obo/> | ||
|
|
||
| SELECT ?document (COUNT(?field) AS ?fieldCount) | ||
| WHERE { | ||
| ?document rdf:type cco:ont00001298 . | ||
| ?document obo:BFO_0000178 ?field . | ||
| ?field rdf:type cco:ont00001243 . | ||
| } | ||
| GROUP BY ?document |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> | ||
| PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> | ||
| PREFIX cco: <https://www.commoncoreontologies.org/> | ||
| PREFIX obo: <http://purl.obolibrary.org/obo/> | ||
| PREFIX owl: <http://www.w3.org/2002/07/owl#> | ||
|
|
||
| SELECT ?data ?document_field ?document | ||
| WHERE { | ||
| ?document_field a cco:ont00001243 . # document field | ||
| ?document_field cco:ont00001765 ?data . # has text value | ||
| ?document obo:BFO:0000178 ?document_field . # has continuant part | ||
| } | ||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| # Pattern Name | ||
| Document Field | ||
|
|
||
| ## Compentency Questions | ||
| 1) What document is this document field a part of? | ||
|
|
||
| 2) How many document fields are in the document? | ||
|
|
||
| 3) What is the string of text associated with this document field? | ||
|
|
||
| ## Intent | ||
| Showing the document field is a part of a document. | ||
|
|
||
| Comes in hand when representing documents with multiple fields, so that we can link more than one ICE to the same IBE. | ||
|
There was a problem hiding this comment. The reference to IBE is a distraction. An IBE can already carry as many ICEs by simply saying ICEx generically depends on IBEy. There was a problem hiding this comment. Let us rephrase: Document Field shows that you can have different parts of an IBE that each stores a different ICE. Would that be ok? There was a problem hiding this comment. Not in my view. I think the cases where one will be working with a single physical document are relatively rare, and so having this as a design pattern is a magnet for making mistake. We've seen that in practice in a variety of cases. What would be more acceptable, if you really want to talk about IBEs is to have two design patterns, one which uses only ICEs and one IBEs, as this one is, and make very clear in the documentation what the consequences of using one versus the other are. And if that is really desirable, allow the data property to be used directly from the IBE or ICE. But again, I'm against this. The design patterns will be seen by new users as suggestions on how to build their RDF data, and so we want to be promoting patterns that are likely to be used correctly. There was a problem hiding this comment. Honestly I struggle to find any cases where you would want to use the IBE patterns. I should. be clear: These aren't just patterns. It's not just a preference about what pattern should be used. They are assertions of fact, and they should properly reflect the reality. In any case of a digital form, it will not apply, because that form will certainly be displayed or stored on more than one IBEs, and the facts will be the same in all cases. That is ICE behavior. In the case of written forms, almost any form these days will be scanned or otherwise copied, and then we're back to the digital case/multiple IBEs that are entirely interchangeable for the purpose of recording information. There was a problem hiding this comment. I keep trying to understand why people keep using this pattern. The only thing I can think of is that they think when they give an IRI for an IBE they interpret that as meaning "some IBE", thinking it valid because, of course, every ICE will have some IBE bearer. But of course that's not what it means. When you give an IRI of a particular it means that specific particular. If you say something is an IBE, that means that sheet of paper, even if that paper has long been shredded and all we have are copies that, from the point of view of the assertion being made, do not necessarily have anything to do with each other. Unless what they have to do with each other is part of the semantics of the term. Such is the case with ICEs. Another way: Just because you've said an IBE bears an ICE, that doesn't mean that anything said about the information on the one IBE is true of another IBE. That's because, at least, IBEs can carry more than one ICE at a time or across time. There was a problem hiding this comment. Alan, am I wrong in understanding that currently the domain of properties such as 'has text value' or 'uses measurement unit' is still limited to IBE? If we are to build a design pattern that is able to connect to data and we have to display the usage of data properties in CCO, then we still have to go through the IBE. There was a problem hiding this comment.
The proper fix is to the properties. From an ontological point of view, all data goes through the content. There's also an outstanding suggestion that these properties be deprecated in favor of a single 'has value' property. In discussion. I'd like to suggest that we do not publish information entity patterns until the information refactoring is done. All it will do is introduce unnecessary churn. Surely there is enough other noncontroversial content for which patterns can be published. There was a problem hiding this comment. @giacomodecolle I'd also like to point out that the language "go through the IBE" is not an ontological way to describe a resolution of a problem, which should focus on what is being asserted and the sensibility/correctness of such an assertion. We aren't solely defining "design patterns", we're making statements about the world. Each such statement should be so evaluated. There was a problem hiding this comment. @alanruttenberg a part of the reason why I see use in modelling information is to use data properties to connect our ontological models to data stored in formats such as datetimes or integers. Currently, the way in which CCO does this is by using data properties such as "has text value", whose domain is an IBE. Previous CCO documentation adopts this design pattern, which requires the user to generate an ICE, connect it to an IBE using a property such as "generically depends on", and then connect the IBE to data using a data property. My newly formed understanding is that the refactoring changed the taxonomies and labels of ICEs, but didn't change the data properties that would allow us to connect data to the ICE. This now puts us in a conundrum, as people using the development version still have to use the previously existing data property that connects data to the IBE, while the taxonomy has moved to favor the use of ICEs as primary modelling targets. Part of the reason why this design pattern is following the old model is that it focuses on showing how to connect data to a graph using data properties, which still needs to be done by connecting them to the IBE. I can pause the publication of design patterns on information until this is resolved if the governance board agrees on this course of action, but I would like to have a comment on how long you (the board) think this will take. Besides the design patterns and the work of numerous volunteers in that group, a number of projects I am currently work on depend on this modeling, and I would like to avoid having to refactor everything (including the design patterns) in a few months. |
||
|
|
||
| ## Structure | ||
| The document has as parts two document fields. One of them carries one ICE, specifically a designative Name. | ||
|
|
||
| Despite using names as an example, this pattern can be used with any other ICE. | ||
|
There was a problem hiding this comment. I'm not sure what part of the pattern you mean that can be used with ICEs. Not all ICEs have document fields as part. If you mean part of the pattern can be used with other ICEs then specify which part. (for instance, a qr code doesn't have document fields) |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| flowchart BT | ||
| E@{ label: "<span style=\"color:black\"><b>Document Field 2</b></span><br>" } -. has text value <br> ont00001765 .-> n1["Mary"] | ||
| n5["<b>Document</b>"] -- rdf:type --> n6@{ label: "<span style=\"color:black\"><b>Document </b><br><b>ont00001298</b></span><br>" } | ||
| n5 -- has continuant part<br>BFO:0000178 --> n7@{ label: "<span style=\"color:black\"><b>Document Field 1</b></span><br>" } | ||
| n7 -- rdf:type --> n8@{ label: "<span style=\"color:black\"><b>Document Field <br>ont00001243</b><br></span>" } | ||
| n9@{ label: "<font color=\"#000000\">Agent 1</font>" } -- rdf:type --> n10@{ label: "<span style=\"color:black\"><b>Agent <br> ont00001017</b></span><br>" } | ||
| n7 -. has text value <br> ont00001765 .-> n11["John"] | ||
| n12@{ label: "<font color=\"#000000\">Designative Name 1</font>" } -- rdf:type --> n13@{ label: "<font color=\"#000000\"><b>Designative Name<br>ont00000003</b></font>" } | ||
| n12 -- designates <br>ont00001916 --> n9 | ||
| n7 -- is carrier of<br>BFO_0000101 --> n12 | ||
| n5 -- has continuant part <br>BFO:0000178 --> E | ||
| E -- rdf:type --> n8 | ||
|
|
||
| subgraph Legend | ||
| AA{Individual} | ||
| BB[Class] | ||
| CC[data] | ||
| AA --> |relation| CC | ||
| classDef yellow fill:#ffe680 | ||
| classDef purple fill:#dbc9ef | ||
| classDef white fill:#ffffff | ||
| class BB yellow | ||
| class AA purple | ||
| class CC white | ||
| end | ||
|
|
||
| E@{ shape: diamond} | ||
| n5@{ shape: diam} | ||
| n6@{ shape: rect} | ||
| n7@{ shape: diam} | ||
| n8@{ shape: rect} | ||
| n9@{ shape: diam} | ||
| n10@{ shape: rect} | ||
| n11@{ shape: rect} | ||
| n12@{ shape: diam} | ||
| n13@{ shape: rect} | ||
| E:::purple | ||
| n1:::white | ||
| n5:::purple | ||
| n6:::yellow | ||
| n7:::purple | ||
| n8:::yellow | ||
| n9:::purple | ||
| n10:::yellow | ||
| n11:::white | ||
| n12:::purple | ||
| n13:::yellow | ||
| classDef yellow fill:#ffe680 | ||
| classDef purple fill:#dbc9ef | ||
| classDef white fill:#FFFFFF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In writing #317 (comment), a proposal for how SPARQL queries are written, I realized that I consider the current pattern an anti-pattern. Instead of using IBEs (Material copy of a document, Material copy of a document field), the corresponding ICEs should be used. What is being asserted in the design pattern is overwhelmingly more likely to be used with ICEs. As it is, it is making a statement about a single piece of paper (or display of same on one computer screen, at one time). Make a photocopy, or display the same thing the next day and we know nothing about those entities. But of course we expect to.
If you really mean this to apply to one and only one copy, please make that abundantly clear in the documentation that this is what you are doing by explaining where this pattern is to be applied. Using the labels in develop will help. But don't.
Aside from fixing this, I note that this will be pulled into develop presumably but is not using the labels from develop.
Also consider adopting the style of SPARQL I proposed in #317 (comment)