On Wed, Jan 04, 2012 at 12:17:31PM +0000, Pete Johnston wrote:
> > Group: LiteralValuePattern
> > Slot: PropertyURI
> > Slot: LiteralValue
> > Slot: LanguageTag
> > Slot: SyntaxEncodingSchemeURI
> > Group: NonLiteralValuePattern
> > Slot: PropertyURI
> > Slot: ValueURI / ValueID
> > Slot: SKOSConceptSchemeURI
> > Slot: ValueLabel
> > Slot: LanguageTag
> > Slot: SyntaxEncodingSchemeURI
>
> The use of "pattern" in the names for "grouping constructs" within the data
> structure seems rather odd to me, and given existing usage in this sort of
> context, I fear it is likely to lead to confusion.
>
> I'm thinking particularly of "pattern matching" as a form of
> "querying"/"selection" or "validation"/"testing" of "instances" of data
> structures.
>
> i.e. In typical usage, a "pattern" isn't a structure or structural component
> (or at least it isn't a component of the data structure - it may be a
> component of a "query" or of some form of "structural schema" used for
> structural validation). Rather, a "pattern" is some set of rules against
> which a set of individual ("instance") structures/structural components can
> be tested.
>
> Consider the case of RDF and SPARQL, for example.
[... cut ...]
I see the problem and must agree...!
> If we want to ensure a harmonization of DCAM concepts and terminology and RDF
> concepts and terminology, and particularly given your warning about "false
> friends", I'd argue against the use of "pattern" in the way you suggest
> above.
>
> I don't have a suggestion for an alternative here, particularly if you wish
> to avoid "statement", but I think it requires something other than "pattern".
Constellation, Construct, Configuration... nah. How to say "pattern" without
saying "pattern"? Everyone: suggestions, please!
I'm open to arguments for keeping Statement but have convinced myself for now
that the sort of ...construct... we have in mind differs so much from an RDF
statement as to make Statement misleading in this context. The notion of
"statement-based" metadata is so fundamental to the message we want to convey
that I think we want to avoid any potential confusion on this point.
Tom
--
Tom Baker <[log in to unmask]>
