JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  February 2012

DC-ARCHITECTURE February 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

2011-02-15 DCAM call - 11:00 EST - report

From:

Thomas Baker <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Wed, 22 Feb 2012 10:09:44 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (168 lines)

2011-02-15 DCAM call - 11:00 EST - report

Attended: TomB (chair), Kai, Jane, Gordon, MichaelP, Aaron, Diane, Mark (IRC), Jon, Antoine
This report: http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-20120215
Agenda: http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconAgenda-20120215
Previous: http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-20120130

----------------------------------------------------------------------
ACTIONs carried forward

ACTION: Tom and Richard to put placeholder for introductory text into wiki document
at http://wiki.dublincore.org/index.php/DCAM_Revision_Draft.

ACTION: Kai and Tom to work on technical part in wiki, e.g.:
    http://wiki.dublincore.org/index.php/DCAM_Revision_Tech
    http://wiki.dublincore.org/index.php/DCAM_Revision
    http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad
    http://wiki.dublincore.org/index.php/DCAM_Revision_Graphics

----------------------------------------------------------------------
Discussion of Tom's proposed "general message"
   https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1202&L=dc-architecture&P=19582

   [[
   Seen as data artifacts, Metadata Records consist of slots holding
   information items in a defined structure. A Metadata Record may describe a
   single Thing of interest (such as a Book) or a cluster of closely related
   Things (such as a Book and its Author). More abstractly, a Metadata Record
   may be seen as a Description Set encompassing just one Description (i.e.,
   about the Book) or multiple Descriptions (about both the Book and the
   Author).
   
   A Description consists of one or more Statements about the Thing Described
   (e.g., stating the Name and Birthdate of an Author). The Thing Described
   by a Description may be identified using a URI. A Statement about the
   Thing Described has one slot for an Attribute (Property) and one slot for a
   Value. Attribute slots are filled with names of attributes (properties);
   in DCAM, attributes are "named" using URIs. Value slots are filled with
   Value Strings, URIs, or blank Value Placeholders. A Value String may be
   stated as belonging to a named set of strings (known as a Syntax Encoding
   Scheme). A Value URI may be stated as belonging to a named set of URIs
   (known as a Vocabulary Encoding Scheme). In practice, Statements may be
   viewed in the context of Statement Sets. Statement Sets may follow common
   patterns.

   The Dublin Core Abstract Model (DCAM) provides a language for representing
   the structure of specific Metadata Records -- put more abstractly, to
   specify a Description Set Profile -- in a form that is independent of
   particular Concrete Encoding Technologies such as XML Schema, RDF/XML,
   RelaxNG, relational databases, Schematron, or JSON.
   
   In order to provide compatibility with Semantic Web and Linked Data
   applications, however, DCAM is fully aligned with the Model and Abstract
   Syntax of RDF. (Note that the RDF abstract model is the basis for -- thus
   distinct from -- concrete RDF encoding technologies such as RDF/XML,
   N-Triples, and Turtle.) Knowledge of RDF is not a prerequisite for
   understanding DCAM on an informal level.

   DCAM provides a language for expressing common patterns of Statements --
   patterns that may be partially or fully encoded using specific Concrete
   Encoding Technologies. Indeed, some readers may find the example patterns
   used in designing DCAM more accessible and useful, as models and templates
   for implementation, than the formal specification of DCAM itself.
   ]]


Jon: "The Dublin Core Abstract Model (DCAM) provides a language for
    representing the structure of Metadata Records in a form that is independent of
    particular Concrete Encoding Technologies such as XML Schema, RDF/XML, RelaxNG,
    relational databases, Schematron, or JSON. That looks like 100% of it to me.
    The rest is commentary."

    GordonD: +1 for Jon's suggestion of a one-liner ...
    Diane: +1 for concise statement first

Antoine: A bit long, but clear. Problem with terminology - we should be ready
    to change depending on alignment with RDF. "Slots" for example. Put disclaimer
    next to text. Would expect to see reference to "grammar".
    Re: mixing reference to syntactic things (slots) and semantic (things
    described): not a problem - need to make the connection between the
    syntactic stuff and things described.

Diane: "A Description consists of one or more Statements about the Thing Described
    (e.g., stating the Name and Birthdate of an Author). " This sentence
    needs to say: "A description about an author...". Otherwise very
    confusing, particularly for those schooled in MARC.

Jon: I agree with the need for the DCAM to be able to be used to create an
    RDFS/OWL specification, and in that sense 'alignment' is necessary.
    I think that one paragraph is feature-complete and represents the 'pitch'
    fairly effectively. I think it's useful to keep specific grammar, such
    as "description set" out of it if possible.

Aaron: Looking at implied distinctions in this first pass - maybe make more
    explicit. I think there is a difference between alignment with RDF and
    dependence on RDF/XML, etc. Do we imply that RDF/XML must be used?

Jon: For me, providing a specific methodology for expressing a DCAM-compatible
    spec in RDFS/OWL is a requirement. If we can't do that then it won't be useful.
    GordonD: +1 Jon - this is what I'm looking for ...

Jon: But if that's all we can do then we limit ourselves to simply solving an edge case.

Aaron: Maybe the abstract model of RDF can provide a linguistic guide for how we do
    that. The terms we use, we would use in DCAM as well. Jon, in RFC, agrees with
    need for DCAM alignment with RDF needed. Aaron: use RDF abstract syntax.

Diane: I understand the traction for trying to use another spec as a basis for this,
    but I'm coming at this from perspective of a non-technical reader.
    I'm not sure the value carries through. The current DCAM is very difficult. We need
    a "DCAM for Dummies" - something more accessible. Concerned we might be going down
    road of complexity.
    Jon: @dih1 +1 for an expanded description

Jon: One more time - this is perfect from my perspective: "The Dublin Core
    Abstract Model (DCAM) provides a language for representing the structure of
    Metadata Records in a form that is independent of particular Concrete
    Encoding Technologies." I would love to see the DCAM be this well-implemented
    across _modeling_ technologies and this simply expressed: http://mustache.github.com/
    
Diane: Jon's one-sentence could be a very good introduction. But these five paragraphs
    could be broken up under headings as additional headings. But try not to cram it all.
    Pretty dense.

Jane: Like Diane's idea of chunking what has been written. Going in a good direction.
    This seems digestible and helpful. Important to keep the "DCAM for Dummies" idea
    on the front burner.

GordonD: We actually need DCAM for librarians, etc. ...
    Jon: @GordonD++
    Diane: Gordon +1, but maybe we need a translation
    Jon: Aaron, librarians should learn DCAM

Aaron: Librarians should learn RDF
    Kai: Aaron +1

GordonD: I mean a librarian's translation of "slot", "description", "statement", etc.
    That is, if we can translate the proposed text into the vocabularies familiar to
    different groups like librarians, then we know the text is a good distillation of
    the abstract ... Librarians already know DCAM - they just use a different terminology.
    Jon: @GordonD exactly

Diane: Aaron, maybe techies need to learn more about where librarians are, in order
    to help move them in a useful direction.

Aaron: Agreed, though we shouldn't be afraid to bring librarians into the wider community
   as well. From someone who inhabits both worlds.

Diane: Some of us have been doing that for some time, but it ain't easy, and we need to
    pay more attention to their needs

Tom: Are we talking about translations of DCAM into French, Chinese... and Librarianese?
    Aaron: +1 @tbaker

Diane: Gordon, yes, Andy once told me that he'd used some library ideas in DCAM.

Tom: Instead of "DCAM for Dummies", how about "DCAM for Librarians" and "DCAM
    for Data Modelers".

GordonD: @Tom, we need to ensure the (familiar) concepts expressed in DCAM
    are seen to be familiar by Librarians, archivists, and anybody who knows
    about relational databases ...
    Tom: @GordonD Understood
    Diane: DCAM for non-technical users.

--
Tom Baker <[log in to unmask]>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

February 2024
January 2024
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
September 2022
August 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
November 2021
October 2021
September 2021
August 2021
July 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
September 2020
August 2020
July 2020
June 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager