Identifier:  http://dublincore.org/usage/minutes/2008/2008-09-21.berlin-4Guidelines.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/.


Guidelines for Application Profiles - discussion
================================================

Tom would like a list of what needs to be done to finish
guidelines.  Do there need to be more things in this document?
Or keep it high level?

Pete - should this be an intro to DCAM too?  This relates
to strings and things issues (literals and non-literals).
We can expand the model section to do this.  This would be
the missing section between sections 4 and 5.

This is also related to VES and SES - could we package them
all together?

Tom notes the difficulty with explaining "literal"
and "non-literal".  

Is the point that non-literal values are "all defined outside
the immediate metadata record" and that non-literal values are
"more controlled and amenable to computer manipulation"?  No.
A literal value with a syntax encoding scheme is "controlled"
whereas a non-literal value used without an encoding
scheme is not.  The distinction is: Can it be described?
Describability is the nub of the issue.

Andy says (eduserv blog): if the topic is considered a literal
value is a descriptive cul-du-sac, no further description of
the topic is possible.

Andrew will paste Andy's blog post on the wiki.

Point of confusion: typed literals.  These can be linked to a
context (cf. W3C DTF), but this is still a cul-du-sac because
you can't say anything more.

There is a problem getting beyond a string value / we have
to get them to understand the difference in functionality
from going from a literal value as a string as something
without mediation to a user, to the next step - they need
to know the value proposition, but starting from the literal
vs. non-literal distinction because they want to help their
users.

Karen tried to make a typology.  But this doesn't map onto
literal vs. non-literal.

Karen's going in the right direction by saying a literal is
a dead-end and non-literals allow more.  But it's too simple,
because something is lost:

We have two columns:
1. literal and non-literal
2. uris, typed...

There is debate on where people start: at authority files
or not?  and we need to acknowledge where they are and move
them to the argument we have to make about these distinctions.

Karen has a post from Jason Tamale (sp?) where he uses a
relational database as a comparison point to literal and
non-literal.

What's the road metaphor for non-literal value?

Can you say that a non-literal value can be (further)
described?  Yes, but this is not enough.  we need to get the
metaphor right.

Can we get back to the metadata:  what you can put in the
way the metadata is modeled is not directly related to display

If you model something as a literal - it can only be one string
(typed or not).  If you model something as a non-literal - you
can add to it, further describing it (linking to other things).

The latter can be sold as added functionality.

It's shared and linked information not created by them.

We can start with the authority control record, but can
take it further.  We can tell them there is more there -
specifically that they can gather more information and link
to it, and this is good because it improves the quality of
the products they produce.

This is the right track because it's a functional
definition/description/scenario.

It is debated that authority control records are a good place
to start, people who know this are not, in fact, our largest
user group.

Other Questions about the Guidelines Document:

Is the invented syntax good?  Do we need to do more of this in
our documentation?  Could just use the xml fragments throughout.

Ultimately it would be nice to see an entirely worked out
example of "my bookshelf".  Also, would be nice to see these
written out in prose, and then show the xml fragment.

Should we add another example or extend the example for a
more compelling case.

[break]

Akira: noticed and error - we can drop the RFC3066 reference
(it should be be RFC4646)
... Tom did some edits 
... it was in section 5 of an early version, but now it's gone

Pete: the diagram in section 4, because it says "book has part
person", not "book as author person".  And in sec. 5 first
bullet, should we add VES, yes we should.  The sentence is
awkwardly worded, but we can add a sentence or half a sentence
about VES as defined by the DCAM.

Tom: let's talk about Andrew's discussion 

Andrew: got more confused the more he looked at it.  We talked
about a way to differentiate between SES and VES.  We have
said many things in the past.  Things vs. strings issue where
VES are literal and SES are non-literals, but we still have
the issue of what a literal and non-literal are, we will
establish that later.  We made a formulation in Manzanillo...?

Tom: In Manzanillo we made a decision about values as either
SES or VES.

Andrew: we didn't make as clear of a distinction, for
example SES.

Pete: We've said SES is equivalent as RDF's notion of datatype,
we have said that there is a lexical space - a set of strings,
and a set of values to which they map, and there are rules of
getting from lexical space to value space.  e.g., W3C DTF,
and there's boolean too, so we have 1, and true that map to
the notion of true, and 0 and false as the notion of false.
this is problematic because it can be seen as a controlled
vocabulary...

Tom: we went through the exercise of clarifying encoding
schemes, see UDC example, see Box example, see ISO 639-2,
representations of the names of languages.  This was productive
because we made clear in the definitions.  It is the set
of conceptual resources or a string - and we put those in
the definitions.

Pete: We have a modelling choice.  Do we want to treat
languages as a set of resources or are we content to take
language tags as values from an SES.  We need to move toward
modeling the world as a set of strings or a set of things.

Andrew: then it's down to the modeling, so how do we want to do it?
All SESs could be VESs, so... does it matter?

Pete: what do you want to do with these values?  So you want
BTs to be things, so we can describe them further

Andrew: in general don't we want to say more things?  

Pete: it depends, that point in time can be described by many
different calendar systems... it's always a trade off.

Tom: everything as an SES, and in GRDDL transforms is made
a SES for HTML.

Andrew: but these things can change... so 

Tom: Is it appropriate to use a new URI for something that
has changed from VES to SES

Andrew: So it comes down to us as to whether we want to model
the world as VES or not.

Tom: it is not appropriate as a datatype (SES) and as a VES
... we see two ways, and we took a stand on that.

Andrew: Working on the idea of how to explain to the community
what literals and non-literals are.

Tom: we have to understand what this document is doing.
We might approach this, we have twenty odd examples, we could
have gone either way (VES or SES), but some were clear-cut
examples, we might walk through these and quote from the title
of the specification to make the point that what is included
is a set of strings or we see it as a set of concepts, to
account for the decision-making process.

Stefanie: question - ISO 639 can be bother a SES and a
non-literal - see example in Karen's Guidelines document.

Tom: gets back to the problem of confusing literal with value
string - non-literal can have value strings and can be typed.
They say "I want a string so I need to model things as a
literal" but they don't have to.

Stefanie: This is important. SES does not mean literal.
VES does not mean non-literal.

ACTION: Andrew will produce another draft of SES and VES
document, looking back at examples we took a stand on in DCMI
Metadata Terms, We decided Box was an SES because of the Box
specification document managed by DC.

Tom: Stuart, what's your experience teaching the difference
between VES and SES?

Stuart: The students don't have a problem.  They grasp it as
well as it is defined.

Tom: we need to move on to other things.  Let's move on to
Profile Review Criteria themselves - to ask how well they work
(for outsiders and insiders).

Profile Review Criteria

Tom: My personal sense is that checking constraints was a
useful exercise.  To what extent will APs fit the DSP model?
Tom thinks the review criteria are good in their present form.