RE: FYI: dear adobe here's an idea for you

IIRC (which I probably don't) a key restriction in XMP is the arrangement of blank nodes which is tree like. i.e. the set of RDF graphs that can be encoded in XMP is a proper subset of those that can be encoded in RDF/XML. Understanding these limitations of XMP would, in my mind, be critical in building an RDFa library that had good XMP compatibility.

I believe RDFa can serialize RDF graphs that cannot be serialized in RDF/XML, and I am pretty certain it can serialize graphs that cannot be serialized in XMP. Thus a restricted subset of RDFa is needed to achieve the XMP compatibility goals.

I am available to attend a San Jose or San Francisco meeting.

Jeremy


> -----Original Message-----
> From: public-rdf-in-xhtml-tf-request@w3.org [mailto:public-rdf-in-xhtml-tf-
> request@w3.org] On Behalf Of Larry Masinter
> Sent: Tuesday, February 24, 2009 1:23 PM
> To: Dan Brickley; Ben Adida
> Cc: Martin McEvoy; RDFa mailing list; Gunar Penikis; Frank Biederich
> Subject: RE: FYI: dear adobe here's an idea for you
> 
> >> I'm happy to help provide advice, guidance, etc.. Adobe is next door to
> >> me, so if we've got the right contacts there, I'm happy to offer going
> >> over there to present an introduction to RDFa.
> 
> The groups working on metadata for media in Adobe are spread
> across the world, including Noida, Hamburg, Bucharest, Seattle,
> San Francisco, San Jose and probably 8 other locations.
> If you mean San Jose, I'm happy to meet and invite local folks,
> let me know.
> 
> > I'd suggest an RDFa representation of their XMP metadata format is more
> > likely to engage attention at Adobe than generic RDF/DC.
> 
> I think what generally engages the attention of Adobe product
> groups are use cases and examples that significantly impact the
> work of customers engaged in creating and updating web content.
> Focus on the workflow uses of metadata -- where does it come from,
> and how is it used -- let the standards follow.
> Of course, compatibility with existing deployed tools that support
> XMP (whether from Adobe or other software sources) is a plus.
> How does RDFa substantially improve things for users, authors,
> publishers, over other solutions?
> 
> > Are http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart1.pdf and
> > http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf  the best
> > places to start?
> 
> Part 1 describes the data model (not arbitrary triples!) and the
> representation of the data model within a (subset of) RDF.
> This is of interest if you're transforming between RDFa and XMP.
> 
> Part 2 describes the standard schemas for XMP. This is important
> if you're establishing standard vocabularies for metadata
> with a shared data model.
> 
> Part 3 describes how XMP metadata can be embedded directly into
> some well-known file types. One important way of associating
> metadata with files is to embed the metadata -- itself in a
> consistent representation -- in arbitrary file types, to allow
> content-type independent manipulation of metadata.
> 
> I'm not sure that's a goal of the "RDF in XHTML task force"
> but I think it might be -- the metadata for the JPEG file
> and the metadata for the HTML file that references the JPEG
> should be equally processable.
> 
> Additional documents:
> 
> http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf
> covers a general mechanism for dealing with compound
> media (objects derived from many parts) as well as
> metadata for "temporal" media (audio, video) which
> varies over time. Since this is more focused on
> "how to" it also has a more examples.
> 
> http://www.pdflib.com/developer/xmp-metadata/ has some pointers
> to use of XMP in the ISO standards for PDF (now owned by ISO
> and not Adobe.)
> 
> http://www.metadataworkinggroup.org/
> has a specification about metadata interoperability.
> 
> For a "starting point", though, there's nothing like
> running code:
> 
> http://www.adobe.com/devnet/xmp/ offers an
> open source  (BSD license) C++ XMP library
> implementing XMP extraction, parsing, and
> manipulation.
> 
> http://labs.adobe.com/technologies/xmplibrary/
> has an XMP library written in ActionScript, also
> open source.
> 
> 
> > I remember XMP used to use a lot of the rdf:Bag,
> > rdf:Seq, rdf:Alt constructs.
> 
> I'm not sure those are used "a lot", but Bag, Seq and Alt are
> part of the data model, as are structures.
> 
> > So one thing to investigate here would be
> > the extent to which data from other XMP-carrying environments (eg.
> > inside PDFs, TIFFs) can be losslessly represented in human-facing RDFa.
> 
> I'm not sure I or Adobe would go along with the characterization
> of PDF, TIFF or other formats that contain XMP metadata
> as less "human-facing".
> 
> But lossless transformation between metadata representations
> is an important goal for improving customer workflows and
> something we support.
> 
> > And on whether XMP-friendly profiles of RDFa usage (eg. some templates -
> > such as might be suggested for Dreamweaver) can be produced.
> 
> > Here is an example from XMPSecificationPart2.pdf
> > (one might imagine this in RDFa with some CSS styling):
> 
> "<xmp:Title>
> <rdf:Alt>
> <rdf:li xml:lang="x-default">XMP - Extensible Metadata Platform</rdf:li>
> <rdf:li xml:lang="en-us">XMP - Extensible Metadata Platform</rdf:li>
> <rdf:li xml:lang="fr-fr">XMP - Une Platforme Extensible pour les
> Métadonnées</rdf:li>
> <rdf:li xml:lang="it-it">XMP - Piattaforma Estendibile di Metadata</rdf:li>
> </rdf:Alt>
> </xmp:Title> "
> 
> The example confused me, since "dc:title" is in the Dublin
> Core namespace (http://purl.org/dc/elements/1.1/), not the
> "xmp" namespace (http://ns.adobe.com/xap/1.0/).
> 
> But I think s/xmp:Title/dc:title/  would help.
> 
> > Larry - looking at the spec, a lot of the examples are exercises in
> > exploring corner-cases for parsing. Can you point us to any kind of
> > repository of real world XMP examples?
> 
> I'll look to see if anyone has published or could publish some
> XMP examples to help people working on interoperability.
> 
> Thanks!
> 
> Larry
> --
> http://larry.masinter.net
>

Received on Wednesday, 25 February 2009 00:11:09 UTC