Identifier:  http://dublincore.org/usage/minutes/2008/2008-09-21.berlin-5Etc.html
Description: This is one part of the minutes for the Usage Board meeting
             of 20-21 September 2009.  See http://dublincore.org/usage/minutes/.

----------------------------------------------------------------------
Unfinished Business: Range for DCTERMS Title 

Range of dcterms:title (Tom) - formal vote to complete unfinished business
-- http://dublincore.org/usage/meetings/2008/09/berlin/terms-titlerange/

Tom proposes that we assign a range RDFS literal to DCTERMS
title, and ask for a vote.

Pete: the proposal is option three in the meeting packet (page 77).

Stefanie: has a problem of word sequences (or something
like that), we do not solve the problem when we only change
DCTERMS title.

Andrew: why not a non-literal?

Tom: Because the implementer community sees it as having a
literal range.

Andrew: How do I describe series using DC?  If it's a literal I
can't link that series title because of contextual information.

Pete: It's the thing that has the title, not the title that's a thing.

Andrew: But i want to link that title .

Diane: Model it differently.

Stefanie: We have a problem with uniform title.

Diane: Do it through relation, don't do it through title.

Andrew: Relation doesn't work.  Why can't DC let me link to title?

Diane: You're having one-to-one problem.

Andrew: A series is an organic whole, and it has a title,
and we want to expose that, we want to link from DC title to
series  title.  If I want to put a description of series on
the web page, why can't I link?

Pete: What is being described?  We have a series that has a
title, and?

Andrew: We have a database that has information about items
and series and creating agencies, and I want to link ...

Pete: You're confusing metadata record and hyperlinks.

Andrew: I am, you're right!

Stefanie: We want a record of the title, we want a
transliteration of a title.

Diane: I think you're looking for a richer schema, which
DC isn't.  It doesn't make sense in a DC context.

Stefanie: It doesn't make sense in a DC context to say that
we have a solution for title and nothing else.

Diane: You want to create an authority record for the title.
You should look at RDA, because that's the mindset they're
working on it.

Stefanie: Akira wants a solution, and does this solve the
problem?

Diane: Tom has established the appropriate boundary (in
my opinion).

Akira: One question.  The issue is only for the title?  Yes.
The description is a separate issue. My colleague says
that title or name of something is still not literal (is my
opinion), but as an approximation of modeling to see a name
as a literal makes things very simple.

Tom: There's nothing precluding creating a property of
"name" with range non-literal.

Akira: name is like URI in natural language, so it should
be unique, and thus it should be literal, but historically
and for many reasons it is not really unique, but still many
people believe a name is unique, thus, the approximation
of literal works in most cases, and simplicity we gain from
modeling it this way is great.

VOTE that the property DCTERMS Title be assiged a range of
RDFS literal (ramification: we need to change Alternative
Title as well).

    In favor: 8 
    Opposed: 0
    Abstain: 0

Vote that the property DCTERMS Alternative Title be assigned
a range of RDFS literal:

    In favor: 8
    Opposed: 0
    Abstain: 0

After lunch, write a description/definition of literal non-literal.

Other Actions
=============

Tom: there are little errors and fixes in documentations
(pg 79 of meeting packet).  We need to take a look and see
if these still need to be done.

1. Action from last november - Joe and Andrew for discussion
at a future teleconference.  Is this something we want to
keep on our active list?  Yes, keep working on it.

ACTION: Joe and Andrew to continue work on Coverage

2. Action on Mikael and Tom to create AP making everything
literals, documenting...

ACTION: Tom (and Mikael) to continue work on this

3. functional requirements of agents against FOAF

Was on a critical path for hosting FOAF, so the question is
whether we want to take this on.  Wo questions: should this
be done and should it be a Usage Board issue?

Andrew: we thought that putting it on the UB agenda it would
get done, but may not be appropriate.

Diane: maybe it's ok.

Andrew: there is still an Agents Community that can pursue this.

Diane: there is some important stuff that needs to be done
before DC can decide whether we can do it.

Tom: we are not going to take it on.  Dan and colleagues
are still working on FOAF, still tweaking in various ways.
In the end, it is owned by two private individuals.  They are
looking for trusted context and long-term preservation of the
namespace.  How can they shore up the long-term credibility?

Diane: we have similar problems in the Registry.  Also,
how do you continue developing something without funding?
Wow do you gain credibility without funding?  FOAF seems
incomplete, and there doesn't seem to be a goal; it looks like
a science project.  There's a need for something like FOAF,
but with more umph and more a sense of where they're going,
and there may be a proposition in there that is of use to
the DC implementers

Andrew: it's not a w3c initiative?  Why isn't it taken up
by w3c?

Pete: they can say it's genuinely community developed.  This is
an advantage to them, but if it went to w3c it would change.
I think there's lots of value to FOAF.

Andrew: Dan wants someone to host it and give it a URI
but also wants to own it, seems incompatible.

Tom: He is looking for a compromise.

Tom: It cuts to the core of the Semantic Web - so the value
is only going to be if they survive over the long term, and
these things get developed in contexts that are in transition,
how do you move from vocab needed to institutionally perserved
vocab.  We not looking to preserve FOAF.  If we had a community
actively puruing this, then it would be one thing, but there
is little to no activity.

Andrew: would like to get the assessment of FOAF finished.

Diane: yes, because this would help Agents community decide
whether to adopt or build their own.

Tom: it would be nice to have a Note from the UB so we can
make a statement about FOAF.  this would be useful.  Comments?

Andrew: I still want to work on it.  But not perhaps not the
person to write it Could draft something.

Pete: which are Usage Board issues?

Tom: whether FOAF conforms to DCAM?  It is being used in SWAP.
Maybe there isn't anything to say about it.

Pete: was trying to get this clear.

Diane: maybe it's just a monitoring function, this will
help us.

Tom: We are evaluating profiles now, so we can look at
vocabularies in a very simple way to increase their visibility.
We have two profiles and they cite terms in several namespaces
and it could be useful to have a list of all of them that
have been used in approved in DCAPs (e.g., FOAF, marc relator).

Julie: this could be useful for reuse, and this would be valuable.

Tom: If we have come in contact to vocabularies in review,
we could simply provide a one paragraph review of them.
Wo in that context we could have a pointer to FOAF.
We can take teleconference time to discuss these namespaces.

Joe: looks like "registered" status of terms.

Pete: you're endorsing data models as well as vocabluaries -
so FOAF has a model, which is different than the FRBR model.

Pete: so you take 5 or 6 properties.

Tom: RDF allows you to take out of context, and this takes
us on a tangent.  So review of FOAF is out of scope.  So we
can drop it as a UB action.

ACTION Drop Action 200708 on Andrew and Tom dropped

4. Principles document by Joe?

ACTION drop Action on Joe to draft document on principles

5. Action on Pete and Tom on amending the naming policy to ensure that dcmi names should not only differ by case
... we have a naming document and a namespace policy
... willing to carry it forward

ACTION Tom (not Pete) will amend the naming policy


6. should we drop Name from namespace policy?
... it makes the page longer, and could use label instead

Julie: names are like headings, making the page readable

Pete: others use a key name 
... FOAF using the shortname or something like that, and then for FOAF they use a Qname
... do you maintain name as a separate thing in your source Tom?

Tom: yes
... it's not that important, what we're doing it's not broken, and tweaking scripts would require careful work
... but if there'd been a loud cheer, then we would do it, but Tom is happy to drop this action item

Pete: the namespace policy document does still talk about term name


NOTE: Tom evaluate use of Name in Namespace Policy Document

7. Andrew to edit term decision tree

Tom: we have relaxed schema requirements, 
... Stuart authored this decision tree, and Mikael was critical because it doesn't tell how to make a new term that is DCAM compliant, we've incorporated part of the decision tree in AP review criteria
... so do we need a document that helps people declare a DCAM compliant term?  Andrew is looking at this in VES and SES document, and do we need a document that provides more guidence, and is this an extension of decision tree?  can we fold this into Andrew's note on VES and SES to incorporate properties and classes?  Andrew?

Questions: does there need to be a user-oriented document on how to create a DCAM compliant term?

Julie: yes

Diane: people think of properties only and underestimate the value of other vocabularies, and they don't understand the value of having stable properties and unstable values of those properties

Stuart: and that is the problem of old decision tree, we wanted to discourage property creation, and I'm not sure it holds anymore

Diane: I think it does hold
... by pushing then to think about vocabularies in a more appropriate form of description is valuable, otherwise they think of everything as properties with literal values, 

Tom: this goes beyond what Tom as thinking, 
... was thinking of an appendix to Karen's paper that says what's a class, a property, an SES and a VES and doesn't say where you differentiate (at properties and CVs for instance)

Diane: here's an example - one community I worked with was the animal behavior group.  wanted to use DC and they decided that there are certain things they wanted to talk about.  they had mating, parenting, feeding behaviors they wanted to describe.  but what they felt was that they needed to create properties that corresponded to those vocabularies - they had a one-to-one view of how properties and vocabularies related, instead of thinking that you'd be describing what a video was about using several vocabs and one property set instead of loading up multiple properties, and you'd have more flexibility if you had seperate vocabs and one property set.   this is common.  term decision tree is valuable because of cases like this.

Tom: but there's an over all tendency to not shy away from subproperty creation

Diane: may not be the same thing

Pete: yes, it's not good to have one-size fits all

Diane: would hate to lose the notion of fixing those problems

Tom: we should get karen's paper right, and see if it sinks or swims, and could be a start of something that is a larger set of guidelines

Diane: maybe it belongs to Using Dublin Core, but we haven't gotten there because it's for certain people

Julie: I think we need to a document like this, not something detailed, maybe a page
... if they need a term "type of tree" then they should know how to make it, so they can be reviewed

Tom: is this something you're interested in?

Andrew: yes, but I would like some help

Julie: will help

ACTION: Andrew and Julie to write a one-page guideline on
creating new terms that comply with the DCAM (replaces the
original action).

ACTION drop Action on Andrew wrt decision tree

8. In our namespace documents we have metadata that states
the publisher is a string (Dublin Core Metadata Initiative)

RESOLVED: use a blank node (option II)

NOTE: check registry script's rendering

Tom: there are lots of APs coming our way.

Andrew: people think the kernal is the best thing DC has done
because it's not too complex.

Tom: there's this levels document.  It has a level one informal
interoperability, etc.  In what way is a levels document a
UB issue and specifically how can UB be of service to those
who want metadata at level one?

Diane: been thinking about revising Using Dublin Core.
it would be nice to look at levels in that context.
Using Dublin Core is written for level one or two

Pete: what can UB say about level one?  it can't say much.
That levels document did capture what some people think.

Tom: Kernal could be level 4 if it were mapped to triples
and the like.  Their aspirations are simpler.  It's not clear
what the UB's role in level one would be.

Andrew: what's going to happen to that document?

Tom: It's currently published on the Architecture Wiki.

Vocabulary Encoding Schemes and Syntax Encoding Schemes (Andrew)
-- http://dublincore.org/usage/meetings/2008/09/berlin/etc-encodingschemes/
   http://dublincore.org/usage/meetings/2008/09/berlin/etc-encodingschemes/SES_VES.pdf

Profile Review Criteria (All)
-- http://dublincore.org/usage/meetings/2008/09/berlin/ProfileReviewCriteria-20080917.html