Identifier:  http://dublincore.org/usage/minutes/2008/2008-09-21.dcub-meeting-notes-raw.txt
Description: This is one part of the minutes for the Usage Board meeting
             of 20-21 September 2009.  See http://dublincore.org/usage/minutes/.


September 21, 2008

9-Noon:

Present: Akira, Andrew, Diane, Tom, Stefanie, Pete, Julie
Guests: Stuart, Jon, Stefan

Guidelines for Application Profiles:

(Tom would like here - a full list of what needs to be done to finish guidelines)

Tom notes that there´s a difficulty with literal and non-literal discussions in these guidelines

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?

Coyle´s distinction: "that non-literal values are all defined outside the immediate metadata record where plain literal values are wide open and anything goes non-literal values are more controlled and amenable to computer manipulation."

a literal value with a syntax encoding scheme is "controlled" and a non-literal value used without 

can it be described? that is the distinction between these.

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

ACTION: Andrew will paste Andy's blog post on the wiki

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

describability is the nub of the issue.  

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

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

Coyle'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 defintion/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 sentnece or half a sentence about VES as defined by the DCAM


Tom: let's talk about Andrew's discussion 

Andrew: hi!
... 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: we made a declaration 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.
... recently Pete found information about language tags
... so 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 Coyle'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 they 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 decieded Box was an SES because of the Box specification document managed by DC.


Tom: what's your experience teaching the difference VES and SES

Stuart: they don't have a problem.  they grasp it as well as it is defined.

Tom: we want to move on to other things
... we have other things on the agenda 
... let's move on to Profile Review Criteria themselves - to ask how well they work (for outsiders and insiders)
... Tom has made small observations


Profile Review Critera

Tom: my personal sense 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


Unfinished Business:
Tom: Range for DCTERMS Title 
... Tom would like to propose 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 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 informaiton 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 apporpriate 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 from 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. actionon 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
... so 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 friends are still working on it, so it's not done
... they want to tweak it, but also it is owned by two private individuals, when they are looking for trust 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?
... how 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?
... no it's not, 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 he wants to own it, is incompatable

Tom: he wants a compromise

Andrew: seems imcompatable

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?

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 at a very simple way to increase their visibility to
... 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
... so 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

Tom: so 

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 published on the Architecture Wiki
... Collections AP does Pete know anything?

Pete: says nothing

EOAgenda

[break]