> -----Original Message-----
> From: ext Stefan Kokkelink
> [mailto:[log in to unmask]]
> Sent: 26 September, 2001 13:16
> To: Stickler Patrick (NRC/Tampere)
> Cc: [log in to unmask];
> [log in to unmask]
> Subject: Re: Poor man's structured value construction versus explicit
> resourceURI values
>
>
> 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.
I fully appreciate the problem, and actually am a fan of the poor man's
structured value construction -- it's very good that it is so well defined
and illustrated in the DCMI documentation. It was simply that the fact
that it should only be used when no explicit RDF classes/URIs are defined
does not seem to be stated in the document herein concerned, and the chance
that folks will simply copy the examples verbatim could result in widespread
practices that are less than optimal.
And insofar as key enumerations are concerned, such as e.g. defined as
recommended values for basic or qualified properties (such as language),
could it not be reasonable for DCMI to either provide URI definitions of
ISO or IETF enumerations, or at least collaborate with such standards
bodies to produce such authoritative URI definitions. But I certainly
understand the need to "draw lines" and don't fault the DCMI for opting
out of such activities.
> > 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.
I fully appreciate that there is an unfortunate lack of authoritative
sources of URI identities for numerous key enumerations, and that it
is not DCMI's direct responsibility to define them. But one would hope
that at least DCMI would promote their definition and use, and detail
the inherent scalability drawbacks of the poor man's construction,
despite it's otherwise positive qualities as a preferred fallback
solution when no explicit URIs are available.
I recall reading recently, though, that the IETF has published some
URIs for a few key enumerations, but just now I can't seem to find the
reference. Perhaps (hopefully) this could become less of an issue (and
if IETF standard language URIs exist, perhaps you could provide some
examples using them in future incarnations of this document? ;-)
> > <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.
Those who take the time to understand the issues will appreciate the
limitations of the poor man's construction and will likely also
appreciate the benefit of using explicit URI identified resources for
property values as much as possible -- however, since lots of folks
in a hurry just copy and modify examples (myself included ;-)
perhaps some alternate resource based examples and clear verbage
would be a good thing.
Cheers,
Patrick
--
Patrick Stickler Phone: +358 3 356 0209
Senior Research Scientist Mobile: +358 50 483 9453
Software Technology Laboratory Fax: +358 7180 35409
Nokia Research Center Video: +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland Email: [log in to unmask]
|