- UsageBoardIssues2010

DCMI Usage Board issues

URI for DCMI

DCMI has coined a URI to identify itself (i.e., the organization Dublin Core Metadata Initiative Ltd) [1]. The URIs [1,2] return the response code 302 and redirect to [3].

The following responses suggest a need to coin URIs for many of the ideas and concepts that DCMI stands for (in addition to its communities and task groups, as we have already discussed). It raises the question of how much we should try to say with triples? And using URIs, how could we leverage such URIs and triples in our most basic user-oriented materials, such as a (completely revamped) FAQ and Glossary?

Reactions from pedantic-web@googlegroups.com.

On Tue, Mar 09, 2010, Stuart A. Yeates wrote: "I think the obvious thing missing from this is a clear distinction between DCMI (the organisation) and DC (the metadata schema). Since confusion between these two is likely, I'd be very tempted to include information about DCMI as publisher of DC in there."
Richard Cyganiak suggests:

The documentation for foaf:nick states: ?The nick property relates a Person to a short (often abbreviated) nickname, such as those use in IRC chat, online accounts, and computer logins.? The property's range is undeclared in the RDFS file, so this should be considered a buglet in FOAF. But till it's resolved, it's perhaps better to avoid the property's use for non-foaf:Persons.
I would prefer if the dct:created literal was a typed literal with datatype xsd:date, although a plain literal is correct as well.
An addition of foaf:logo to the description would be a nice touch.
There should be some metadata about the *file* that describes the DCMI as well, that is, some statements about <http://dublincore.org/ DCMI.rdf>. I would recommend to state values for the properties dct:title, dct:created, dct:modified, dct:license, dct:creator, foaf:primaryTopic.

Note: We're getting into recursion, or at least into a discussion on metametadata. Should we think of creating a file http://dublincore.org/DCMI.rdf.rdf with information about http://dublincore.org/DCMI.rdf?

A human-readable variant of the RDF file, served via content negotiation, would be quite nice. On Apache, this can be done quite easily by enabling the multi_views module, and adding a </DCMI.html> file. Apache turns </DCMI> into a generic content-negotiated document.
As Stuart already said, DCMI is perhaps best known for the DC Element Set. You could state that DCMI created it, perhaps both in the dct:description and explicitly in RDF triples. This would help pinning down the referent of the URI.

Corrections to [http://dublincore.org/documents/profile-guidelines/ DCAP Guidelines]

ACTION 2009-10-16: Tom to make correction in DCAP guidelines regarding ISO639-2 as proposed in consultation with co-author Karen Coyle.

Pete on 2009-07-23: On a related note, I see that in the "Guidelines for Dublin Core Application Profiles":

In the text in section 5, dcterms:ISO639-2 is (correctly) referred to as a SES, but in the XML version of the DSP in Appendix B, firstly the reference is to dcterms:ISO639-3, and secondly it is referred to as a VES.

ACTION 2009-10-16: Tom to add resource class constraint to DCAP guidelines as proposed in consultation with co-author Karen Coyle.

Also I think in that example, each Description Template should have a Resource Class constraint, for the classes Book and Person respectively. As it stands at the moment (without those constraints), I think a description of a resource of any type will be bound to both templates, which fails the requirement in DSP section 3 that a description should be bound to exactly one DT. We should make this clearer in section 5 too, I think.

Thread in dc-architecture:

Well-known URIs

http://www.rfc-editor.org/rfc/rfc5785.txt

It is increasingly common for Web-based protocols to require the discovery of policy or other information about a host ("site-wide metadata") before making a request. For example, the Robots Exclusion Protocol <http://www.robotstxt.org/> specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-agents how to discover privacy policy beforehand. While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these scenarios. When this happens, it is common to designate a "well-known location" for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with pre-existing resources. To address this, this memo defines a path prefix in HTTP(S) URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites' URI space.

Property for "Status"

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1004&L=DC-ARCHITECTURE&P=12781
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1004&L=DC-ARCHITECTURE&P=18257
Two issues:

a property to relate a resource to its status, such as the dcterms:status that Bernard was looking for
a set of corresponding status values. As the draft [1] acknowledges, the statuses could be modeled using URI values rather than strings, which is what Bernard (and I) are looking for. As it is likely that "the exact meaning of stable/unstable/testing/archaic will vary from project to project," URIs could help sort that out. Some URIs, such as the status "DCMI Recommendation", would be completely context-specific. The property itself does seem like a pretty obvious piece of low-hanging fruit...

DCMI Metadata Terms in RDFa

http://ivan-herman.name/2010/05/28/self-documenting-vocabularies-using-rdfa/

Definition of http://purl.org/dc/terms/language

The range of dcterms:language is the class http://purl.org/dc/terms/LinguisticSystem. On the other hand the comment says "Recommended best practice is to use a controlled vocabulary such as RFC 4646". But RFC 4646 does not define languages as resources, only language codes. URIs from http://lingvoj.org can be used as values of dcterms:language, which is consistent since lingvoj.org ontology defined its main class "Lingvo" as a subclass of dcterms:LinguisticSystem, and lingvoj.org URIs for languages are built upon codes conformant to BCP 47 (including RFC 4646).

Why RFC 4646 is recommended is probably a legacy issue, because RFC 4646 obsoleted RFC 3066, which in turn obsoleted RFC 1766, and RFC 1766 was recommended for use with the "language element" in the original Dublin Core RFC 2413 of 1998 [3]. Nobody has ever raised an issue with this usage comment, that I am aware.

As of 2010-10-11, RFC 5646 has obsoleted RFC 4646.

XML Namespaces in DC-DS-XML and RDF/XML

The RDF/XML "namespace documents" currently say things like:

dc:title rdfs:isDefinedBy <http://purl.org/dc/elements/1.1/> .

And

<http://purl.org/dc/elements/1.1/> dcterms:title "DCMI Namespace for the Dublin Core Metadata Element Set, Version 1.1"@en-US .

(and so on)

There is arguably a contradiction being introduced between what XML Namespaces says the URI http://purl.org/dc/elements/1.1/ identifies and what the RDF data says it identifies. The RDF data doesn't explicitly type that resource, and doesn't say it's a member of a class which is disjoint with the class of XML Namespaces - though the text in the Namespace Policy document does say pretty much that. Arguably it makes no sense to say that an RDF property is in any way "defined by" an XML Namespace, which sort of implies that http://purl.org/dc/elements/1.1/ must identify something other than an XML Namespace.

The other issue is whether there is a distinction between what the XML Namespaces spec means by "identifies" and what RDF means by "denotes". Can a single URI "identify" an XML Namespace but also "denote" something else?

This is the "pig farm" question that Patrick Stickler raised back in 2004. Basically he was saying there were two options:

(i) ignore that the use of http://purl.org/dc/elements/1.1/ as an XML Namespace name might imply any sense of what that URI _denotes_ (in the RDF sense), and go ahead and say what we want it to denote (or what the community has been using it to denote). A hardline version of "namespaces are just punctuation", if you like.

(ii) acknowledge that the use of http://purl.org/dc/elements/1.1/ as an XML Namespace name means that that involves, or might involve, some sense of denotation, or some other constraints, "surrender" the use of that URI for that purpose, and actively steer clear of using that URI for some other purpose.

Patrick was perhaps arguing that while there was an argument for doing (i), it would be wiser to do (ii) (recognise that the pig farm exists and build elsewhere). See e.g.

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0409&L=DC-ARCHITECTURE&P=23827

We ended up ignoring Patrick's advice and doing (i). Can perhaps be justified by saying that there is nothing in XML Namespaces which carries any sense of denotation in the RDF sense.

DC terms in OWL

Should DCMI Metadata Terms be specified more strongly using OWL?

From: http://groups.google.com/group/pedantic-web/msg/24d8eaaebca1d3b2

 On Wed, Mar 03, 2010 at 08:39:37AM -0800, Jonathan Rees wrote:
 > > On Wed, Feb 24, 2010 at 05:27:19PM +0000, Antoine Zimmermann wrote:
 > > > Another slight problem of owl:equivalentProperty, though arguably
 > > > minor, is that it is not part of the RDF/RDFS vocabulary. So, a pure
 > > > RDFS reasoner or RDFS tool would simply ignore the two implicit
 > > > rdfs:subPropertyOf.  There is no reason to assume that all RDFS tool
 > > > support the OWL vocabulary.
 > >
 > > Antoine raises another point on which I would appreciate feedback
 > > on DCMI's work.
 > >
 > > DCMI Metadata Terms [e.g., 1] are currently defined entirely
 > > using RDF and RDFS.  Domains and ranges were assigned to most
 > > DCMI properties in 2007, as discussed in [2], but every DCMI
 > > property is still declared simply to be of type rdf:Property --
 > > not of type owl:DatatypeProperty, owl:ObjectProperty, or
 > > owl:InverseFunctionalProperty, etc, as in FOAF [3].
 > >
 > > DCMI metadata terms started to be coined in 1995, two years
 > > before RDF even began as a project, so much of DCMI's efforts
 > > have been about evolving with the times.  Though we have
 > > certainly noticed the rising use of OWL for defining
 > > vocabularies, nobody has ever proposed that we revisit DCMI's
 > > RDF-based style for declaring terms.  Indeed, Antoine's point
 > > above makes me wonder whether there might in fact be good
 > > reasons to continue along this current path - or, if we were to
 > > start using OWL vocabulary, to preserve compatibility with RDFS
 > > tools by using it only in addition to RDFS vocabulary.
 > >
 > > I would be very interested to hear views from members of this
 > > list on this question.  As always, DCMI tries to promote
 > > solutions that can straightforwardly be imitated by others,
 > > so the general question is whether it is still good practice to
 > > declare such a vocabulary using just RDF and RDFS, or whether
 > > the use of OWL significantly enhances its usability, and if so,
 > > in what ways.
 > 
 > The DC terms are very popular, and in particular many users of OWL
 > (and OWL-DL in particular) use them or adapt data sources that use
 > them. The practice is generally to make a copy of DC and then edit it
 > to turn it into an OWL or OWL-DL file. The popular ontology editor
 > Protege even provides such a DC variant as part of its distribution.
 > 
 > I think users would be served better by having a common OWL-DL version
 > of DC, whether provided by DCMI or by someone else. Protege's is close
 > to being such (although it is based on dc: elements instead of dct:
 > terms). One problem is the question of whether the properties should
 > be annotation properties or object/data properties, which matters for
 > DL. IIUC Protege takes the position that the dc: properties are all
 > annotation properties, while Bibo says that the dct: properties are
 > object/data properties. I could fully sympathize if DCMI didn't want
 > to get into the middle of this feud.
 > 
 > Best
 > Jonathan
 > 
 > http://groups.google.com/group/bibliographic-ontology-specification-group/browse_thread/thread/55e19fa2a18e8fdf?hl=en
 > http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl

See also http://lists.w3.org/Archives/Public/public-xg-lld/2010Nov/0109.html - Jeff Young arguing that DCMI should upgrade vocabulary to distinguish DatatypeProperty and ObjectProperty.

Legacy usage comments implying the use of string values

Pete, 2009-03-19, points out on dc-usage:

dcterms:coverage: "Where appropriate, named places or time periods can be used in preference to numeric identifiers such as sets of coordinates or date ranges."
dcterms:relation and dcterms:source: "Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system."
Pete, 2009-04-22, Maybe comment for dcterms:coverage should read: "Where appropriate, named places or time periods can be used in preference to sets of coordinates or date ranges."

RDF schema issues

http://dublincore.org/2008/01/14/dcterms.rdf#MESH should not contain "#" sign? Some diagnostics get this as an error message.
xsd:date for dates.
English as "en" or "en-US"?
http://dublincore.org/schemas/dcterms.rdf or so, redirecting to the latest version - like SKOS and FOAF - redirect or just internal URL rewrite
http://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-abstract - a click on the Refines value (http://purl.org/dc/terms/description) jumps to RDF schema. Expected: jump in the document to the definition of dcterms:description.
Use "in-range-of" as FOAF does: http://xmlns.com/foaf/spec/#term_Document. E.g.: <a href="#terms-description">http://purl.org/dc/terms/description</a>
Need prominent link to RDF schemas in dcmi-terms
URI subject of triples in the RDF representation is the same as the namespace URI, e.g., http://purl.org/dc/dcam/ http://purl.org/dc/terms/publisher http://purl.org/dc/aboutdcmi#DCMI. This is consistent with http://www.w3.org/1999/02/22-rdf-syntax-ns# http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://www.w3.org/2002/07/owl#Ontology, but not with http://www.w3.org/2004/02/skos/core http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://www.w3.org/2002/07/owl#Ontology. What is current best practice, and should we change the RDF schema accordingly?
Related to the above, should the RDF representation include a triple with "rdf:type owl:Ontology"?

== Getting access to purl.org'd RDF/XML from Javascript via CORS headers ==

http://groups.google.com/group/persistenturls/browse_thread/thread/d4c5d9880b4fb5fb See http://enable-cors.org for a bit more info. The idea is that it allows javascript apps to read DC schemas. Whether they need to is up for discussion of course.

Getting the Dublic Core schemas exposed to JS involves adding a single CORS header, details below - Tom Dehn would need to cover the purl.org side of things.

Instructions (and discussion thread) at: http://lists.w3.org/Archives/Public/public-lod/2010Oct/0181.html

DC in OWL - Jeff Young input

Also: notion of shortcut properties.

== DC alignment with FOAF

<owl:Ontology rdf:about="http://www.geonames.org/ontology">
  <dcterms:isReferencedBy rdf:resource="http://www.geonames.org/ontology/documentation.html"/>
  <foaf:isPrimaryTopicOf rdf:resource="http://www.geonames.org/ontology/documentation.html"/>

How redundant are the two properties? Could foaf:isPrimaryTopicOf be declared as subproperty of dcterms:isReferencedBy?

Dan says: There may be some linked meaning, but 'being referenced by' something doesn't imply that the former's topic is the latter, much less primary topic. He has wondered about 'mentions' as a milder-than-topic link type useful for named entity recognition tools to output. On the other side, perhaps something can even be primarily about something without even specifically referencing it. Images and audio for example are doc forms that don't have explicit referencing mechanisms. Not sure how far dc can be stretched there...

foaf:Agent equivalentClass dct:Agent (FOAF already says this)

one might reasonably define the terms "agent", "org" and "project" in a way that makes them not disjoint
re mapping dc and foaf, whether to use class machinery to talk about sets of people (eg, dct:AgentClass)
foaf:membershipClass for a foaf:Group as dct:AgentClass?

awkward straddling of the schema / instance data divide

http://wiki.foaf-project.org/w/VocabMapping

Douglas Campbell suggestions

DCMI owl:sameAs-ing (or similar) alignments, eg: foaf:name -> dc:title. skos:prefLabel -> dc:title. foaf:Person -> dcmitype:Entity. skos:Concept -> dcmitype:Concept. Note http://dublincore.org/documents/dcmi-terms/#classes-Agent, which only happens not to be part of the DCMI Type Vocabulary.

MARC Relators

2005 http://dublincore.org/documents/dc-elem-refine/
2005 http://dublincore.org/documents/usageguide/appendix_roles.shtml
2005 http://dublincore.org/usage/documents/relators/
2005 http://www.loc.gov/loc.terms/relators/dc-contributor.html
2005 http://www.loc.gov/loc.terms/relators/dc-relators.html
2005 http://www.loc.gov/loc.terms/relators/dc-relators.xml
http://id.loc.gov
MARC properties are subproperties of dc:contributor - what about dcterms:contributor, etc

Inverse properties

dct:isReplacedBy owl:inverseOf dct:replaces

> UsageBoardIssues2010