Property - for discussion

[kcoyle]

"Property" in the simple template is an element of description that is associated with an entity. In DCAM and DSP what we are currently calling ''property'' is the DSP ''statement''.

DSP:
description with 1..n
    statement with 1..1
       value

In the simple model, the property is the only required column. Consensus at meetings is that this could be a literal string, but most usefully would be an IRI. Each property has an optional associated property label for human readability.

[kcoyle]

Some analogous terms used elsewhere:

DSP: statement Property BIBFRAME: Property Sinopia: property ISO/IEC 11179: data element YAMA: statements IMS global: field ODRL: property OGC: Property DCAT: property Wikidata: property

(edit and add others that you know)

[tombaker]

In my reading, the notion of "statement", is not the DSP equivalent to "property". DSP does not have "statements" per se - it has "statement templates" and points off to DCAM for the definition of what a "statement" is. In DCAM, a statement is a property-value pair, and in DSP, a statement template holds property and value constraints. This snippet from the DSP XML syntax makes the distinction clear:

    <StatementTemplate minOccurs="1" maxOccurs="1" type="literal">   

            <Property>http://xmlns.com/foaf/0.1/name</Property>

            [...value stuff...]

    </StatementTemplate>

In DSP terms, <Property> is called a "property constraint" because its value, http://xmlns.com/foaf/0.1/name constrains the theoretically infinite set of possible properties down to just foaf:name. At least, that is how I recall Mikael's explanation.

Bottom line: DCAM and DSP both use "property" for what the other frameworks call "property".

[kcoyle]

@tombaker This makes me wonder if we want to talk about "statements" in our model even if there is no statement column in the template. Statement would be the property, the cardinality of the property, the value type and the value constraints. Does that make sense? I find it useful to think of these as a logical unit.

[philbarker]

Yes, I think that a "statement" (or "profile statement" or "statement template) would be a good name for a row in the csv.

[philbarker]

My main ask here is that the definition of the "property" speficies that it relates to something from an external source (i.e. is a term from the base vocabulary / the specification being profiled)

[kcoyle]

@philbarker I like the idea of using "statement" for a row. It would actually be an expansion of the DCAP concept because each statement could include both the entity and the property/value pair for the entity. That is something we would have to decide. In an early version Tom created a spreadsheet with headers (as excel files). I've done a csv of one of those. As you can see, that follows the DCAM model in which there is an entity template section and a statement template section. That makes our model flatter than the original DCAP which followed a more hierarchical structure. I think that having the statement be a row is like having the row be a graph or shape (as Tom would call it). Each statement would be complete, from the entity through the value. And presumably the resulting rows would not need to be read in any order.

[briesenberg07]

@philbarker

Yes, I think that a "statement" (or "profile statement" or "statement template) would be a good name for a row in the csv.

@kcoyle

I like the idea of using "statement" for a row.

This seems like a helpful way to conceptualize rows (as versus columns) to me also. Would the prefix+namespace-only rows we've discussed throw a wrench into such a definition?

[philbarker]

This seems like a helpful way to conceptualize rows (as versus columns) to me also. Would the prefix+namespace-only rows we've discussed throw a wrench into such a definition?

I don't think so, it just means that not every statement in an application profile is what DCAP calls a statement template.

[tombaker]

If Benjamin is saying that a row should contain just one statement, then I think this would argue for keeping namespace prefix declarations not only in separate columns but also in separate rows (ie, the statement templates would not overlap at all with the namespace prefix declarations).

This seems like the cleaner way to do it, though esthetically perhaps not quite as pleasing because the spreadsheet would be less compact.

On Tue, May 5, 2020 at 11:46 AM Phil Barker notifications@github.com wrote:

This seems like a helpful way to conceptualize rows (as versus columns) to me also. Would the prefix+namespace-only rows we've discussed throw a wrench into such a definition?

I don't think so, it just means that not every statement in an application profile is what DCAP calls a statement template.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcmi/dcap/issues/59#issuecomment-623958777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOBJWXRMFYAMX7R5FHDOLRP7N7NANCNFSM4MPKPYXA .

-- Tom Baker tom@tombaker.org

[tombaker]

@kcoyle Another case where we had great discussion but I think we have resolved. Close?

[kcoyle]

Decision was made to use propertyID for the column, propertyLabel for the label column, and refer to the row elements related to the propertyID in documents as "statement constraints".