Hi Tom,
I appreciate I'm jumping in and nit-picking on particular issues, but one comment on the proposed terminology for structures:
> A more detailed view for the benefit of technical editors...
>
> Here is another, slightly simplified, way to view the _current_ DCAM
> Description Set Model (using Python-esque indentation):
>
> Group: Description Set
> Group: Description
> Slot: Described Resource URI
> Group: Statement
> Slot: Property URI
> Group: Literal Value Surrogate, a type of Value Surrogate
> Slot: Value String
> Slot: Syntax Encoding Scheme URI
> Slot: LanguageTag
> Group: Non-Literal Value Surrogate, a type of Value Surrogate
> Slot: Value URI
> Slot: Value Encoding Scheme URI
> Slot: Value String
> Slot: Syntax Encoding Scheme URI
> Slot: LanguageTag
>
> The above view already simplifies away the soon-to-be-obsoleted underlying
> distinction between plain and typed RDF literals [2].
>
> What I propose to replace this with is:
>
> Group: DescriptionSet
> Group: Description
> Slot: DescribedResourceURI / DescribedResourceID
> 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.
The RDF Concepts doc
http://www.w3.org/TR/rdf-concepts/
specifies the syntactic structures/structural components: graph, triple, subject, predicate, object, etc
The SPARQL doc
http://www.w3.org/TR/rdf-sparql-query/
specifies a "query language" in which queries are constructed using "graph patterns", against which individual ("instance") RDF graphs can be tested.
i.e. a SPARQL "graph pattern" is a component of a SPARQL query, but not a structural component of an RDF graph
So in the DCMI context, if we use a concept of "pattern", I'd expect that to appear in the context of the Description Set Profile spec (or whatever succeeds that in "the new world") i.e. although the current DSP draft doesn't use the terminology of "patterns", what that draft calls "templates" are (or play the role of) what I think of as "patterns".
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".
Pete
> Picture the visual diagram with:
>
> -- nested enclosing boxes for the Groups
> -- little boxes for Slots nested inside the Groups. These are the boxes
> ("fields") that get filled in with data values.
>
> Tom
>
> [1] http://dublincore.org/documents/abstract-model/
> [2] http://www.w3.org/2011/rdf-wg/track/issues/80
>
> > My proposal is that the entities of the DCMI Abstract Model (plus
> > DC-TEXT) be limited to the following entities:
> >
> > -- Grouping constructs
> > DescriptionSet
> > Description
> > LiteralValuePattern
> > NonLiteralValuePattern
> >
> > -- Syntactic slots
> > DescribedResourceURI / DescribedResourceID
> > PropertyURI
> > ValueURI / ValueID
> > LiteralValue
> > ValueLabel
> > LanguageTag
> > SyntaxEncodingSchemeURI
> > SKOSConceptSchemeURI
>
>
> --
> Tom Baker <[log in to unmask]>
|