Bloody hell! I have that call on my Architecture calendar for tomorrow morning :-(. I was going to join...
Stuart
> -----Original Message-----
> From: DCMI Architecture Forum [mailto:[log in to unmask]]
> On Behalf Of Thomas Baker
> Sent: Thursday, August 19, 2010 10:57 AM
> To: [log in to unmask]
> Subject: Report - Architecture Forum telecon - 2010-08-19
>
> DCMI Architecture Forum - Report - Telecon 2010-08-19, Thursday
>
> Agenda: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=DC-
> ARCHITECTURE&P=3323
>
> Expected: Tom Baker (chair), Pete Johnston, Mikael Nilsson, Dan
> Brickley, Jon Phipps
>
> ----------------------------------------------------------------------
> RDFa 1.1 profile
>
> Pete: Term mappings are possible - "title" mapped to
> "dcterms:title", etc. Also prefix mappings: if you use
> CURIEs, you can put the prefix mappings into the document
> or put them into a profile and just point to the profile.
> People don't need to put everything into the instance
> documents. The scope of an RDFa profile does not
> necessarily need to be same as scope of a namespace -
> one profile can cite prefixes and term mappings for
> different namespaces. Can be used to bundle a set of
> commonly used namespaces. I have no strong opinion
> on whether DCMI should do this. Instead of doing in a
> vacuum, could think of concrete use case. For example,
> when exposing DCMI Metadata Terms, we are experimenting
> with RDFa, using a concrete set of terms in combination.
> As part of that work, we could create a profile covering
> the set of terms used to describe DCMI Metadata Terms,
> including references to terms in other namespaces. From a
> social perspective, that would be a good thing to do.
>
> Tom: Bookmarking as action for the medium term. DCAM
> discussion currently a higher priority.
>
> ----------------------------------------------------------------------
> DCMI feedback on HTML Microdata
> Proposed feedback to [log in to unmask]:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=DC-
> USAGE&P=52
>
> Nods of approval from participants on the call. No red
> flags. Tom will review and post.
>
> ----------------------------------------------------------------------
> DCAM: Past, present, future
> http://dublincore.org/architecturewiki/DcamInContext
>
> Dan: DCAM importance perhaps more sociological than
> technical. Dates from an era in which RDF was not
> deployed and looked risky. DCAM was a compromise: given
> a community model, "these are the things in RDF of value
> for us". Nowadays, with SKOS and Linked Data, RDF is
> looking healthier. We could take the position that it
> was a document "from its time".
>
> Mikael: What DCAM does that is important to DC community:
> it provides a set of typical ways of expressing simple
> statements. RDF itself is very pure and abstract; it can
> be hard to see how to organize triples. DCAM - different
> view on triples. Designed for specific communities with
> heavy resources, such as libraries, with lots of properties
> describing resources. (As opposed to other communities
> with lighter metadata.) Turn to DCAM: "how do I encode
> my metadata"? Even if they do not follow DCAM in detail,
> they may follow its patterns. If DCAM were removed, would
> still be a need for 20-30 typical patterns. These patterns
> could be linked to the syntaxes like RDFa and RDF/XML.
>
> Jon: I challenge the assumption that DCAM hasn't had takeup.
> It has in a social context, in framing the problem.
> And people use it training. Agree it could be helpful
> to de-emphasize DCMI-specific language. See it as a
> transitional object between the XML model of the world
> and RDF. Problem with DCAM: there is not always a clean
> distinction btw syntax and semantics.
>
> Pete: Broadly agree with Dan. It was created at
> a particular point in time to perform that social
> function. Agree with Jon, could in theory be seen as
> transitional thing btw classical Dublin Core world and
> RDF world. Not clear in own mind whether this is the time
> to push the bridge into history and move to a pattern-based
> approach or whether to try to maintain it as bridging device
> (i.e., continue current course). Both approaches possible.
> Maybe continue to maintain and couch as purely syntactic.
> Or deprecate and replace with series of patterns. Want to
> make cleaner separation btw DCAM abstract syntax, on one
> hand, and DSP/Application Profiles. In RDF context, could
> offer that sort of functionality using query patterns.
> Also attracted to Dan's proposition (let go and move into RDF
> world).
>
> Tom: We need to go into the Pittsburgh meeting with
> a set of possible outcomes, prioritized as to which we
> see as most desirable -- a straw-man recommendation to
> be supported or refuted.
>
> Pete: As a next step, need to get options onto the mailing
> list for discussion.
>
> Mikael: DCAM maybe not best as a normative model, which it
> is today, but an informative document -- for documenting
> patterns. That ties in with Pittsburgh meeting: the
> important point is to find what problems people actually
> are having and need to solve regarding application profiles
> in the RDF, Linked Data, and DC worlds. The very existence
> of DCAM provides a point of reference: a way to structure
> your metadata (with the additional part, DSP).
>
> Tom: When writing [1], didn't seem to make sense to discuss
> DCAM without discussing DSP which, in a sense, provides
> the rationale for having a DCAM. Everyone please give my
> deliberately syntax-oriented summaries of DCAM and DSP a
> closer read to see if they are both accurate and clearly
> understandable. Tried to characterize both without using
> jargon -- a fine line, because in so doing I didn't want to
> create yet more jargon.
>
> ----------------------------------------------------------------------
> Joint meeting, DCMI Architecture Forum and W3C Library Linked Data
> Incubator Group
> http://www.asis.org/Conferences/DC2010/program-
> sessions.html#jointmeeting
>
> Title: Application Profiles for Linked Data: Models & Requirements
> (Parts 1 & 2)
> Convenors: Tom Baker, Emmanuelle Bermes, Antoine Isaac
> Sponsors: DCMI Architecture Forum and W3C Library Linked Data
> Incubator Group
> Date/Time: Friday 22 October, 2:00-5:30pm
> Abstract: Application Profiles for Linked Data: models and
> requirements"
>
> This two-part meeting will look at current approaches to
> application profiles -- methods for documenting the content
> of descriptive metadata to promote the design of compatible
> metadata applications and maximize the coherence of metadata
> in a Linked Data environment. Starting with a review of
> the approach based on the DCMI Abstract Model, including
> the Description Set Profile constraint language and
> Singapore Framework for Dublin Core Application Profiles,
> the meeting will also consider other emerging approaches
> to specifying and documenting metadata patterns for use
> in Linked Data. By taking a fresh look at requirements
> in a rapidly evolving environment, this meeting aims at
> identifying and prioritizing areas where future work may
> be needed.
>
> ----------------------------------------------------------------------
> Next steps
>
> -- Tom to post comments on HTML Microdata.
>
> -- On dc-architecture:
> Review the wiki draft [1] for correctness and clarity.
> Define range of possible courses of action, moving forward.
> Encourage discussion of which course to follow.
>
> -- On another telecon in second half of September:
> Prioritize scenarios, decide on course of action to recommend.
> Approve wiki draft for circulation, e.g., to LLD list.
>
> [1] http://dublincore.org/architecturewiki/DcamInContext
|