Title:         Other actions
Identifier:    MEETINGS:/2008/09/berlin/etc-actions/.index.html
Source:        MEETINGS:/2008/09/berlin/etc-actions/index.txt
Directory:     MEETINGS:/2008/09/berlin/etc-actions/
Created:       2008-09-17

ACTION 2007-11-23: Joe and Andrew to edit a discussion of issues with the
element Coverage http://dublincore.org/usageboardwiki/IssuesWithCoverage
for discussion on a future telecon.  (Note: 'spatial' and 'temporal' are
"correct" but 'coverage' is too broad -- it allows for topic and this is
in conflict with 'subject' [TK] -- this is an Application Profile issue
[TB].)  (This issue is on the back burner for now.)

ACTION 2007-08-26: Tom and Mikael to create a draft "Simple Dublin
Core" AP using the 1.1 namespace and which models everything
as literals. Document the legacy functional requirements and
the organizational context for this AP.  See discussion at
[http://dublincore.org/usageboardwiki/SimpleDcDiscussion
SimpleDcDiscussion].

ACTION 2007-08-26: Andrew, Tom, and Dan B, in context of Agents
TG, to finish the assessment of FOAF against the functional
requirements. Include context describing kinds of places where FOAF would
be useful and where it wouldn't be useful.  Following this assessment,
the TG to propose/recommend a course of action to DCMI Directorate.
See http://dublincore.org/agentswiki/FoafReview.  Update 2007-12-12:
Andrew to progress in January.

ACTION 2007-03-17: Joe to draft a document discussing issues related
to principles and purpose of UB decision-making.  (The context was
the decision to define ISO639-2 as a set of codes.) Update 2008-01-23:
will flow out of profile review criteria.

2007-12-22 (Tom). There were several cases in which
we could have given classes names that differed from
property names only in terms of case (e.g., given
dcterms:accrualMethod: dcterms:AccrualMethod instead of
dcterms:MethodOfAccrual; given dcterms:extent: dcterms:Extent
instead of dcterms:SizeOrDuration). (The other cases were
dcterms:instructionalMethod, dcterms:language, dcterms:license,
dcterms:Period.) Should the naming policy specifically address
this issue?

2007-12-22 (Pete and Tom). The [WWW]Naming Policy says that
"applications are well advised to normalize case when parsing
terms for identity comparisons. Prudence mitigates against
the use of case to distinguish between alternative identities
of related terms in any namespace, and it is DCMI policy that
such distinctions not be made within its own namespaces, so
it is unlikely that errors would be introduced by normalizing
case." This is at odds with how DCMI currently treats "names"
and URIs: While we can say that _DCMI_ won't assign two term
URIs that differ only in case, we can't say that other term
creators won't do that (and they are perfectly within their
rights to do so.) Moreover, we should be encouraging people
building applications which create or consume DC metadata to
take care to _respect_ case in URIs, _not_ to ignore it.

2007-12-11 (Tom). The meeting notes are currently available
only on stage - see [WWW]Usage Board meetings and telecons.

2008-01-15 (Tom). Drop "name" from /dcmi-terms/ and related
documentation?  This would make the document shorter, hence
that much more readable.  Note that "Name" is currently
defined as "A token assigned to the term, unique within the
term's DCMI namespace".  (The glossary of DCMI Namespace
Policy should perhaps be updated with this definition.)

ACTION 2008-03-26: Andrew to edit Term Decision Tree -
http://colab.mpdl.mpg.de/mediawiki/ApplicationProfiles/TermDecisionTree,
proposing a more appropriate title.

    Pete points out that XML datatypes are identified with URI but 
    not documented in an RDF schema.  General consensus that we should
    relax the requirement for a schema - enough to assert that something
    is (for example) an RDF property.

    Noted Mikael's objection that TermDecisionTree does not
    provide guidance on how to declare a new term so it becomes
    DCAM-compatible.  Tom differentiates between a DCAM compliance
    test and a full vocabulary review.

    Do we really need ection differentiate VES/SES here?
    Consensus that we need an explanation, but not clear whether
    this belongs in TermDecisionTree.

    Andrew should write up criteria for differentiating SES/VES,
    though they do not necessarily belong in TermDecisionTree.
    Will first write, then we can decide where to put it.

----------------------------------------------------------------------
Small problem with namespace documents

-- Pete has pointed out that dcterms:publisher is used with a literal
   value in the namespace documents for http://purl.org/dc/terms/, etc
   http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=dc-usage&P=2654

   In
        http://purl.org/dc/elements/1.1/
        http://purl.org/dc/terms/
        http://purl.org/dc/dcmitype/
        http://purl.org/dc/dcam/
   we say

        Namespace-URI dcterms:publisher "The Dublin Core Metadata
        Initiative"@en-US .

   i.e. we use the new dcterms:publisher property with a literal value.

   But the definition of that new property says the range of
   dcterms:publisher is the class dcterms:Agent.

   i.e. I think we've been tripped up by our own introduction of ranges.

   I think we need to do one of the following:

   (i) revert to using the dc:publisher property, for which range is
   unspecified so a literal object is OK (even if a bit absurd in some
   ways)
   (ii) change to using a blank node as object

   Namespace-URI dcterms:publisher _:x .
   _:x rdf:value "The Dublin Core Metadata Initiative"@en-US .

   (iii) coin a URI for DCMI as Agent and use that as object (and ideally
   that URI should either be a # URI or do the 303 thing because
   DCMI-as-Agent is not an information resource). (Maybe we already have a
   PURL that serves this purpose, but I suspect we aren't very clear about
   whether many of the existing PURLs (other than the term URIs) denote
   docs or other things)

   I'm guessing this is actually generated by the scripts so may need
   someone to tweak them.