Hi Patrick,
thank you for the feedback! Some comments below.
<snip>
> I am, however, concerned with the apparent promotion of what you call
> the "poor man's structured value construction" for values which are
> members of standardized, explicit enumerations. I understand how
> difficult it is to craft good examples that illustrate a particular
> concept or methodology, and don't fault the publication for the
> particular examples, per se, but I percieve a danger of readers
> following the examples as specific suggested practices, and this will
> result in a horrendous explosion of needlessly redundant subgraphs.
The problem is the following: The DCMI encorages people to use
encoding schemes for the values of DC properties. However, in most
cases they are no RDF classes defined for the schemes. For example,
there is no RDF class/URI defined for the Mathematical Subject
Classification
and DCMI certainly is not the authority to provide one. So what to do
in these cases? We decided to adopt the usage of rdf:value as described
in the RDF specification. The poor man's structured value construction
should only be used if there are no RDF classes/URIs available.
> A case in point: the use of anonymous nodes specified for rdf:type,
> rdf:label, and rdf:value as the value of the dc:language property. If
> such a practice were taken in contexts where language is defined for
> billions of resources one will have an untenable proliferation of
> redundant sub-graphs.
>
> <snip/>
> In cases such as e.g. standard defined language values, one should
> utilize an explicit RDF resource representing each language, for
> which is defined resource specific properties only once, and other
> properties such as dc:language should refer to the explicit resource
> only.
Yes, it would be great to have URIs for the different language codes.
If the anonymous resource given in example 2.3.1 had a canonical name,
we could resue that name. Sadly, they don't have a URI.
> <snip/>
> I'm sure that all of the above is fully appreciated by the authors
> of, and contributors to, this document. I simply wished to suggest that,
> as many people will likely follow the examples detailed in the document
> exactly, as a form of standard practice, it would IMO be wise to address
> this issue of the risk of prolific redundancy when the "poor man's
> construction" is employed, and recommend that it's use be limited to
> cases where an explicit resource cannot be defined explicitly and
> referenced by URI as a property value.
Yes, perhaps this should be made clearer.
Best regards,
Stefan
|