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

Hello Jeremy, Larry, Dan, Ben all that have responded to this question the freed back was very positive.

I am more inclined to agree with Jeremy I believe the XMP and RDFa approach may be incompatible and restrictive for both parties.

I was thinking the simplest way to achieve this may be either as Dan mentioned a simple RDFa template or by adding extra functionality via a third party exchange add-on that provides the author with a RDFa document type and the five properties that don’t already exist in XHTML, @about, @property, @resource, @datatype and @typeof.

It would be great if Jeremy and Ben and any others at some time can present an introduction to RDFa to those concerned at Adobe, because if RDFa did appear in Dreamweaver everybody would be in a win/win situation, The would be authors of RDFa would win because it will give them the ability to add site wide semantics to their documents very easily, The RDFa community would win because RDFa could be easily adopted by newcomers and add to the implementations list, Adobe would win because more people will buy their software because it has RDFa functionality.

I understand that features that do get in Dreamweaver are largely driven by demand, I believe there is a demand for RDFa it just may not be realized yet.


Best wishes

Martin McEvoy

http://weborganics.co.uk/


-----Original Message-----
From: Jeremy Carroll [mailto:jeremy@topquadrant.com] 
Sent: 25 February 2009 00:10
To: 'Larry Masinter'; '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


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 Thursday, 26 February 2009 18:50:36 UTC