Hi Tom,
"DCAM Statement" reads indeed cumbersome. And you may well drop it, if you indeed keep stuff like LiteralValuePattern or NonLiteralValuePattern in the AM: coining a term in the AM to reify an choice between only two alternatives is not really productive.
Now, if you want to keep something for it, I find StatementSet *really* ugly. It's in fact still as confusing as "statement" currently is.
Alternatives could be:
- "semantic slot": I see in your "DCAM Revision Scratchpad" that you plan to have "Syntactic slots", you could have a coherent story here.
- "PropertyValueSlot": a straightforward announcement of what's in. Of course "Slot" could be replaced by "Pattern" if people prefer (but Pete seems opposed to it). And "Value" could be replaced by "Object" , to better align with the RDF terminology ("PropertyValue", which would be logical following the current DCAM category, reads a bit as a mixture of RDF and UML terminologies).
By the way the last comment leads me to suggest a possible re-wording of your LiteralValuePattern and NonLiteralValuePattern into LiteralObjectPattern and NonLiteralObjectPattern.
And finally: why not "Resource" instead of "NonLiteral"?
Antoine
> On Tue, Jan 03, 2012 at 02:19:21PM -0500, Tom Baker wrote:
>> I propose to limit the entities of the DCMI Abstract Model to the following,
>> and to use the same names for a DC-TEXT-inspired notation (which could be
>> folded into the "technical" DCAM document and used for examples):
>>
>> Record
>> DescriptionSet
>> Description
>> StatementSet - alternative suggestions welcome - this will require discussion!!
>
> An RDF Statement -- a Subject-Predicate-Object triple -- is so significantly
> different from a DCAM Statement -- an attribute-value pair plus optional
> dcam:memberOf and rdf:value statements about the value -- that I'm thinking it
> is perhaps unhelpful to call them both "statements".
>
> StatementSet would capture the notion that (what is now called) a DCAM Statement
> is mappable to more than one RDF Statement, and the word StatementSet is roughly
> comparable to DescriptionSet. However, this is arguably sub-optimal because the
> attribute-value pair at its base consists of just a Predicate and Object.
>
> ValueDescription comes to mind as an alternative, inviting a comparison to
> Description itself, which could be renamed ResourceDescription, but I don't
> like that direction. The term AttributeValuePair misses the notion of
> additional dcam:memberOf and rdf:value information about the value.
>
> Might we just drop the notion of a "DCAM Statement" altogether and refer just
> to Literal and Non-literal Value Patterns -- for which PropertyURIs, ValueURIs,
> ValueIDs, and ValueStrings and ValueLabels, with their LanguageTag,
> SyntaxEncodingSchemeURIs, and SKOSConceptSchemeURIs, would simply provide the
> slots?
>
> Tom
>
|