Corey
Typo in the formatted date; should read 2012-07-16 Monday 1100 EDT ...
Cheers
Gordon
On 09 July 2012 at 23:55 Corey A Harper <[log in to unmask]> wrote:
> Dear All,
>
> With apologies to both Tom & Kai, it looks as though the best time for
> our next call is Monday, July 16, at 11am Eastern Daylight Time:
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=7&day=16&hour=15&min=0&sec=0&p1=179
>
> If we decide it worthwhile, we may wish to have a followup call when
> Tom is available on Thursday, July 26.
>
> I will circulate an agenda before the end of the week, and also post
> another summary message to the list in the next few days.
>
> Date: 2012-07-17 Monday 1100 EDT
> Dial-in: +1-218-936-4141, access code 334034
> IRC: irc://irc.freenode.net/#dcmi.
> Mail: http://www.jiscmail.ac.uk/lists/dc-architecture.html
> Doodle: http://www.doodle.com/hxnpngmprrrdzxir
> Expected: Richard, Corey, Antoine, Karen, Mark, Jon, Aaron, Gordon, Michael
>
> Thanks,
> -Corey
>
> On Fri, Jun 29, 2012 at 9:49 AM, Corey A Harper <[log in to unmask]> wrote:
>
> > Dear all,
> >
> > Among my actions from our last call (minutes below) was to set up a
> > Doodle Poll for a July call. My availability at the 11am EDT time-slot
> > in July is already limited, but I think there should be enough choices
> > here for us to find something:
> > http://www.doodle.com/hxnpngmprrrdzxir
> >
> > In the next week or so, I will write a summary of my thoughts on our
> > June 8 call and post to the list, including subsequent thoughts from
> > you all on Syntax Encoding Schemes.
> >
> > Looking forward to our next discussion.
> >
> > Best,
> > -Corey
> >
> > On Fri, Jun 8, 2012 at 1:50 PM, Thomas Baker <[log in to unmask]> wrote:
> >> DCAM telecon - Report - 2012-06-08
> >>
> >> This report:
> >> http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx
> >> Agenda:
> >> http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconAgenda-201206xx
> >> Attended: Tom, Karen, Antoine, Aaron, Richard, Jon, Gordon, Mark, Corey
> >>
> >> ----------------------------------------------------------------------
> >> Summary of actions taken
> >>
> >> ACTION 2012-06-08: Corey to put up Doodle poll for early July call.
> >>
> >> ACTION 2012-06-08: Aaron to propose archival example.
> >>
> >> ACTION 2012-06-08: Corey to push discussion on dc-architecture to
> >> consolidate
> >> the progress made on this call.
> >>
> >> ----------------------------------------------------------------------
> >> Accepted minutes of previous call
> >>
> >> 2012-05-15
> >> http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-20120515
> >>
> >> ----------------------------------------------------------------------
> >> Design patterns
> >> http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns
> >>
> >> Gordon: Clarification on minutes: "ACTION: Gordon to put reference on
> >> wiki."
> >> probably refers to ISBD. This is done.
> >>
> >> Tom: Moving on to Design patterns. Does "order of elements" question in
> >> ISBD
> >> make it out of scope for our goals? Unsure it does.
> >>
> >> Karen: What is in DCAM and what is in Application Profile? Let's start
> >> with
> >> the ISBD Publication Statement design pattern.
> >>
> >> Gordon: In ISBD, we have parallel situation in MARC. We can anticipate the
> >> same
> >> thing in RDA. Inidividual elements that have importance on their own, but
> >> for
> >> various reasons librarians like to deal with combinations of these
> >> elements.
> >> The variation in Karen's Name example is that elements need not be present,
> >> but
> >> when present they are required. Aggregation statements are needed because
> >> it
> >> is necessary to differentiate between two places of publication related to
> >> same
> >> publication, versus two places related to different publishers. Need to
> >> identify statements as well as separate instance components separately.
> >> Cannot
> >> disentangle from the repeatability issue. If Publication Statement is
> >> repeated,
> >> then you have two publishers. These aggregated statements generally needed
> >> to
> >> be manipulated as a whole piece of metadata. But also need to be broken
> >> down
> >> into component parts. When this repeats, will be necessary to identify
> >> statements as well as constituent components. This example crops up all
> >> over
> >> library MD schemas. And in ISBD, more than one level of granularity.
> >>
> >> Tom: You stopped short of talking about presentation order.
> >>
> >> Jon: See http://www.dlib.org/dlib/january10/hillmann/01hillmann.html "RDA
> >> Vocabularies: Process, Outcome, Use", section titled "Aggregated
> >> Statements".
> >>
> >> Corey: Nooooo! Please, we must stop relying on punctuation to have semantic
> >> meaning!!! Please?
> >>
> >> Jon to Corey: It's the rules that require it. Aggregated statements are
> >> simply strings and the semantic meaning is in the aggregate.
> >>
> >> Gordon: Sometimes the order is absolutely essential. In other cases,
> >> delimited
> >> by punctuation. In traditional metadata schemas. Once we disaggregate, then
> >> clearly the sequencing and order important. Place of publication comes
> >> first.
> >> Sequencing is governed by cataloging rules. Cataloging tradition. This is
> >> mainly display oriented. We are reaching back into the murky depths of card
> >> catalogs. All you saw was the instance values. It was assumed that the
> >> users
> >> would know where to look for place of publication first, then publisher.
> >>
> >> Jon: Also ordering.
> >>
> >> Gordon: No, these are not access points, just parts of descriptions. Mainly
> >> a
> >> layout issue. So the order is important.
> >>
> >> Karen: This is why I offered the other example - the enumeration statement
> >> for
> >> a journal article - volume, number, date - taken together. But this is a
> >> purer
> >> example because it is semantic but not display oriented.
> >>
> >> Aaron: @kcoyle +1 on not designing for display.
> >>
> >> Jon: But despite the fact that it's not an 'access point' it's still very
> >> similar and still representative of a syntax encoding scheme. It's a
> >> definition
> >> for encoding a string.
> >>
> >> Aaron: Name heading example? I mean this:
> >> http://wiki.dublincore.org/index.php/DCAM_Revision_Example_Name_Heading
> >>
> >> Karen: I proposed a pagination example, but nobody responded so I didn't
> >> write
> >> up. Name has display issues but no algorithmically derived order.
> >>
> >> "I think that a better example would be the enumeration elements for a
> >> journal article citation: volume, number, date, pagination. These can be
> >> re-combined in various types of displays, e.g.
> >>
> >> v. 1, n. 7, March/April, 1997. pp. 156-158 (1997)1:7<156>.
> >>
> >> I could write this one up if people think it is useful."
> >>
> >> From:
> >> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1205&L=DC-ARCHITECTURE&F=&S=&P=31694
> >>
> >> Gordon: Agree. The thinking in ISBD DSP is that display issues should be
> >> handled by an AP. Second use cases for aggregated statements: that they are
> >> repeatable. If they are dealt with individually we get the wrong
> >> assignments of
> >> [??]. Traditional: surname first.
> >>
> >> Gordon: [???what???] = place of publication with name of publisher in
> >> separate
> >> statements.
> >>
> >> Karen: Our goal? To me, in terms of DCAM: to decide whether a SES should
> >> include order.
> >>
> >> Jon: SES is quite literally how to encode a string.
> >>
> >> Karen: Date is a single string.
> >>
> >> Jon: SES is a single string.
> >>
> >> Gordon: Separate elements at one level of granularity, but at aggregate...
> >> If we regard SES as single literal - the object of a triple - then for
> >> display
> >> and punctuation issues this is purely an AP issue - you can for example
> >> conceive of a perfectly useful literal coming out as a string. Nothing
> >> intrinsic about order except syntax imposed by cataloging standard. But if
> >> we
> >> look at repeats, then they need to be kept in box or bundle. Each element
> >> has
> >> its own semantics. But in some instances these literals have to appear in a
> >> certain order.
> >>
> >> Richard: But a literal with meanings supplied by the encoding scheme? (i.e.
> >> ISO 8601).
> >> Rather than meaning supplied by the metadata schema itself (i.e. Dublin
> >> Core)?
> >>
> >> Jon: "Each syntax encoding scheme is a class (of literals)."
> >> http://dublincore.org/documents/abstract-model/ Syntax encoding scheme =
> >> http://www.w3.org/2000/01/rdf-schema#Datatype "A set of strings and an
> >> associated set of rules that describe a mapping between that set of strings
> >> and
> >> a set of resources. The mapping rules may define how the string is
> >> structured
> >> (for example DCMI Box) or they may simply enumerate all the strings and the
> >> corresponding resources (for example ISO 3166)."
> >>
> >> Richard: +1 jon
> >>
> >> Gordon: See my recent blog post, which uses the publication statement
> >> example:
> >> http://managemetadata.com/blog/2012/05/20/taggregations/
> >>
> >> Corey: Bwahahahahah: "DCMI Box"....
> >>
> >> Jon: Question: Does this need to be redfined, and if so why? If the
> >> definition
> >> is ok, then how does it get expressed in a machine-processable way? Is the
> >> class SES an equivalentClass or a subclass of rdfs:datatype? If it's a
> >> sublass, what distinguishes it? -- I'd like to submit that we supply a way
> >> to
> >> provide specific methods for encoding and decoding an SES. I don't think
> >> it's
> >> useful to say that a dcam:ses is NOT a subclass of Rdfs:datatype
> >>
> >> Aaron: Am I missing something here? Why create a special SES class? Why not
> >> just use rdfs:Datatype?
> >>
> >> Jon: Because I personally want machine-processable encoding and decoding
> >> instructions attached to a dcam:ses. DCAM refines RDFS and doesn't mirror
> >> it.
> >>
> >> Gordon: @jon +1
> >> Richard: @jon +!
> >>
> >> Aaron: Makes sense to make SES equivalent to rdfs:Datatype.
> >>
> >> Jon: Disagree. DCAM value-added. Opportunity for people to define datatype
> >> with
> >> specific [], without having to go through IETF guidelines.
> >>
> >> Karen: Do you see part of DCAM work to define how to articulate that schema
> >> in
> >> machine-actionable way?
> >>
> >> Jon: Would like to see Perl/Java encoding scheme...
> >>
> >> Karen: What form would they take? Program code?
> >>
> >> Jon: Instructions for machines. Do you have XML schema for doing this?
> >>
> >> Antoine: Jon +1 BUT THAT'S ALSO WHAT RDF DATATYPES ARE ABOUT. IT'S JUST
> >> THAT
> >> NO ONE DOES IT.
> >>
> >> Aaon: @antoine, @chrpr +1
> >>
> >> Corey: This is where we need DCAM as both best practices and technical
> >> specification. E.g.: "Use XML schema here".
> >>
> >> Gordon: Use case for decoding an SES literal: there are many library
> >> records
> >> which are OCRd from catalog cards.
> >>
> >> Jon: Why not sub-class it and provide specifics. An SES is an
> >> rdfs:Datatype,
> >> but also has additional properties associated with it.
> >>
> >> Richard: "In this specification, a datatype is a 3-tuple, consisting of a)
> >> a
> >> set of distinct values, called its _value space_, b) a set of lexical
> >> representations, called its _lexical space_, and c) a set of _facet_s that
> >> characterize properties of the _value space_, individual values or lexical
> >> items." http://www.w3.org/TR/xmlschema-2/#typesystem
> >>
> >> Aaron: What different about an X Date? Corey's question is good: examples
> >> for
> >> how an SES might look.
> >>
> >> Jon?: Example of a piece of software that can encode and decode. Attach XML
> >> schema to that property, for example...
> >>
> >> Corey: jonphipps++
> >>
> >> Jon: want to provide some property that says there is some schema for
> >> decoding
> >> it. If I want to encode or decode a date, I need to find some code that
> >> will do
> >> it.
> >>
> >> Richard: @jon +1
> >>
> >> Karen: Yet it sounds like dangerous territory.
> >>
> >> Corey: That's awesome - I like this idea. Going back to ISBD example.
> >> Linters
> >> that deal with MARC data - parse and verify - "here's code that works with
> >> this
> >> SES" - a huge value-add.
> >>
> >> Corey: SES notion doesn't contradict rdfs:datatype, but instead enriches
> >> it.
> >> Properties around defining this more thoroughly. Building _on_top_ of rdf &
> >> rdfs.
> >>
> >> Jon: When I define an SES. In my definition, I will provide .. for your
> >> particular usage, to define a property to say how to encode or decode it.
> >> Have
> >> a place you can go to reference them. Matter of having "in this data" that
> >> you
> >> just collected, here is how to decode it. Or "here's a way to decode it".
> >>
> >> Karen: This feels to me more of an application profile than an abstract
> >> model.
> >>
> >> Jon: Encoding method and decoding method. What are the methodologies for
> >> each?
> >> Dcam:encodingMethod Dcam:decodingMethod - properties pointing to...
> >>
> >> Antoine: There is a knowledge structure in that string.
> >>
> >> Jon: It's a datatype - an encoding scheme.
> >>
> >> Antoine: Should we aim at doing something besides validating it?
> >>
> >> Karen: We have moved into the application profile area. Different apps may
> >> encode or decode in an application-specific way.
> >>
> >> Richard: Are there examples of other datatypes that are as complex as our
> >> ISBD
> >> examples? Existing XML datatypes seem more like simple primitives.
> >>
> >> Corey: jonphipps++ (again) DCAM is foundation for DCAPs. Karen's exactly
> >> right,
> >> and DCAM has to provide the functionality to make this work...
> >>
> >> Jon: We are looking at how DCAM gets used in DCAP. We have a SES. When
> >> using a
> >> SES in AP, attach properties to SES "these are my methods". The content of
> >> that
> >> property is defined in context of AP.
> >>
> >> Aaron: We are talking about subclassing...
> >>
> >> Antoine: do not understand encoding/decoding the string to *what*...?
> >>
> >> Corey: An application profile builds out data suitable for specific
> >> application
> >> environments based on rules and principles defined in DCAM and its related
> >> constructs (i.e., SES, etc).
> >>
> >> Jon: [scribe missed]
> >>
> >> Karen: Those methods are associated with Application Profiles.
> >>
> >> Antoine: *anything* an XML schema, a particular RDBMS (or NoSQL) structure,
> >> a
> >> more granular RDF-based format...
> >>
> >> Antoine: @corey: I hate that. It's assuming that statements in DCAM are not
> >> only represented by statements. (I mean, DCAM statements)
> >>
> >> Jon: Can have my own encoding method. In canonical description of an SES.
> >> Method not required for an SES. Should be defined, made available as part
> >> of
> >> SES. Dublin Core SES has ability to associate encoding and decoding
> >> methods.
> >>
> >> Karen: This brings DCAM closer to DCAP than it was before.
> >>
> >> Jon: Providing properties useful for defining DCAP. DCAM/2007 leaves too
> >> many
> >> things undefined.
> >>
> >> Antoine: They are still statements. They work the same way when encoded to
> >> be
> >> part of the RDF Graph. But the reality is, our implementation details are
> >> never
> >> all going to be purely RDF based. We're defining a universal interchange
> >> format, I think...
> >>
> >> Jon: DCAM/2007 also does not differentiate itself from RDF. It provides a
> >> few
> >> additional semantics but replicates alot. We should be looking at how
> >> existing
> >> semantics fit in a "true" abstract model - how data gets expressed in
> >> different
> >> models.
> >>
> >> Antoine: @corey: RDF is about encoding as little information in the string
> >> as
> >> possible. That's why datatypes are not used much. I don't think DCAM should
> >> have a different approach.
> >>
> >> Corey: This fits a usecase we have at NYU - subclassing
> >> BibliographicCitation -
> >> preformatted for how they look in displays. Sits alongside unformatted.
> >>
> >> Corey: Antoine, I agree, though I think the problem is that RDF basically
> >> excludes those who have use cases too complicated to fit into that space.
> >>
> >> Aaron: To bring this back to design patterns: how would this be used to
> >> express ISBD examples?
> >>
> >> Corey: DCAM is being designed to offer a _pragmatic_ layer on top of RDF
> >> and
> >> the Semantic Web's idealism (which sometimes borders on dogma and
> >> pedantry...)
> >>
> >> Jon: Looking at Pub Statement as SES - specific set of rules for creating
> >> that
> >> statement - those rules could be expressed machine-actionable way. Like in
> >> RDA
> >> aggregated statements. Components. Takes properties into single literal
> >> that
> >> has specific order, punctuation - but only maybe. In MARC - things that are
> >> a
> >> bear to decode.
> >>
> >> Antoine: @corey, I agree, still it's about sending messages. To stretch a
> >> very
> >> liberal approach to its limit, RDF/XML is a SES.
> >>
> >> GordonD: ISBD follows the RDA approach: all components of an SES are RDF
> >> properties.
> >>
> >> Karen: The encoding is not really machine-actionable. Decoding is closer to
> >> that.
> >>
> >> Antoine: @corey (so we should put some boundaries to how liberal we can
> >> be).
> >>
> >> Aaron: Only makes sense when the Publication Statement is a string, not
> >> when
> >> broken up -- so it is a fairly specific usecase.
> >>
> >> Karen: In every case where you have multiple things, but the whole can
> >> repeat.
> >> You can have multiple titles with multiple subtitles. Alot of this stuff
> >> goes
> >> away when we use identifiers for things, but not all. Alot of what we have
> >> should be replaced with URIs.
> >>
> >> Corey: I like that this is creating guidelines for people who need to do
> >> complicated things. Really complicated things may not be best practice.
> >> Giving
> >> an out for people who want to do crazy things in silos. Fine to explain how
> >> to
> >> do this best, but this is not the best way to use RDF.
> >>
> >> Jon: Part of question is whether we are just talking about RDF.
> >>
> >> Gordon: We are not starting with a clean slate: these examples are what we
> >> have, not what we want.
> >>
> >> Antoine: @jon: we can replace RDF by XML in this example.
> >>
> >> Karen: This is why I was wary of using ISBD as an example. Not a good use
> >> case
> >> because this style is no longer best practice. Would like to think of more
> >> defensible use cases for SES.
> >>
> >> Antoine: @jon (or anything that conveys data through a string...).
> >>
> >> Antoine: But it's like breaking a date atring into day/month/year, each of
> >> which has it's own semantics and is a distinct data point and has an
> >> entirely
> >> different meaning when expressed as month/day/year, both of which are
> >> perfectly
> >> valid date datatypes.
> >>
> >> Gordon: Support from DCAM/RDF/whatever is not going to stop ISBD, MARC, RDA
> >> becoming better practices.
> >>
> >> Karen: @Gordon I suspect that ISBD will die some time after MARC is put to
> >> rest.
> >>
> >> Gordon: But it may encourage those communities to listen, learn, and do
> >> quicker
> >> than might be otherwise.
> >>
> >> Antoine: @Jon: yeah, it's about finding the right balance between what only
> >> a
> >> couple of people would be interested in parsing/validating in a specific
> >> way,
> >> and what one think is worth communicating as formal (DCAM) statements.
> >>
> >> Gordon: These communities need evolution, not revolution: the past must be
> >> secured before the future is explored.
> >>
> >> Antoine: what I'm trying to get away from is having an SES 'defined' by a
> >> set
> >> of written instructions (like taxonomies so often still are) and having the
> >> ability to provide instructions to a machine to process it.
> >>
> >> Jon: Antoine, RDF/XML is an SES in the broadest possible sense.
> >>
> >> Antoine: Jon, yes, I think we'd need some example that are still on the
> >> "good"
> >> side of the balance to strike.
> >>
> >> Aaron: +1 @antoine__
> >>
> >> Antoine: @rubinsztajn: please no EAD as one SES
> >>
> >> Aaron: @antoine: Ha!
> >>
> >> Jon: We have a bunch of SES examples in RDA too.
> >>
> >> Corey: Thanks everyone! Super productive!!
> >>
> >> ACTION 2012-06-08: Corey to put up Doodle poll for early July call.
> >>
> >> ACTION 2012-06-08: Aaron to propose archival example.
> >>
> >> ACTION 2012-06-08: Corey to push discussion on dc-architecture to
> >> consolidate
> >> the progress made on this call.
> >>
> >> --
> >> Tom Baker <[log in to unmask]>
> >
> >
> >
> > --
> > Corey A Harper
> > Metadata Services Librarian
> > New York University Libraries
> > 20 Cooper Square, 3rd Floor
> > New York, NY 10003-7112
> > 212.998.2479
> > [log in to unmask]
>
>
>
> --
> Corey A Harper
> Metadata Services Librarian
> New York University Libraries
> 20 Cooper Square, 3rd Floor
> New York, NY 10003-7112
> 212.998.2479
> [log in to unmask]
|