Action item on additional example for Foreign Part in MCE Best Practices document.

[Arms, Caroline]

Francis,

Many thanks for pursuing this with Graham.  My first instinct is to like the idea of using a relationship established by Editeur/ONIX.  It suggests that relationships don't always have to "belong" to OOXML.  I think other metadata schema owners would be much more likely to follow the more open practice of establishing a relationship in a space they control.  For example, I could see the PREMIS folks doing that.

For PREMIS (Data Dictionary for Preservation Metadata), see http://www.loc.gov/standards/premis/.   I did not suggest PREMIS as an example because (a) PREMIS is of little interest outside the libraries/archives community and (b) any decision-making process would be very slow.  But they would find the ONIX example as a precedent they might follow.  Since PREMIS already uses id.loc.gov for identifiers associated with the PREMIS schema, they would probably want to use an id.loc.gov URI rather than a purl.  See http://id.loc.gov/preservationdescriptions/
  
Thanks again.

   Caroline

Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource    http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution **

-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Wednesday, November 25, 2015 8:32 AM
To: Arms, Caroline; 'MURATA Makoto (FAMILY Given)'; e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Caroline, Murata-san

I have discussed this with Graham Bell at EDItEUR. Interestingly, he has had similar questions about a media type for ONIX from Bill Kasdorf, regarding the embedding of ONIX records inside EPUB files. So I think he is coming around to the idea that there may be some value in registering one or more media types for ONIX (there may be a need for a JSON media type as well as an XML media type, although that probably doesn't concern us). 

On the question of a relationship type for ONIX, Graham wonders whether it would be better to use a URI more like the namespace URI for ONIX. I know this wouldn't have the "guaranteed" permanence of a PURL, but since this is just an example, does that matter?

Kind regards,

Francis



-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com]
Sent: 23 November 2015 18:53
To: 'Arms, Caroline' <caar at loc.gov>; 'MURATA Makoto (FAMILY Given)'
<eb2m-mrt at asahi-net.or.jp>; e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Caroline

I think that in general terms your example is fine. I think it could be argued that it is unlikely that anyone would want to embed a whole ONIX for Books Product Information Message in a WordprocessingML document. A more realistic example would be to embed a single ONIX for Books Product record relating to the document. However, the distinction might not be important for our purposes.

Kind regards,

Francis



-----Original Message-----
From: Arms, Caroline [mailto:caar at loc.gov]
Sent: 23 November 2015 17:57
To: 'Francis Cave' <francis at franciscave.com>; 'MURATA Makoto (FAMILY Given)'
<eb2m-mrt at asahi-net.or.jp>; e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Murata-san, Francis,

I had been assuming a content/media type for XML  could be used for an ONIX record.  Is there some reason something more specific is needed?

My comment about content/media type was more in relation to the steps Chris indicated needed for his .mov example.  If a foreign/unknown part is added to a package, should there be an appropriate entry in [Content-Types].xml?
I don't think it could be assumed  that there is already one.

Francis, apart from these details, are you happy with my  example in general?

    Thanks.   Caroline


Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution
**

-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com]
Sent: Monday, November 23, 2015 7:45 AM
To: 'MURATA Makoto (FAMILY Given)'; e-SC34-WG4 at ecma-international.org
Subject: RE: Action item on additional example for Foreign Part in MCE Best Practices document.

Caroline, Murata-san

There is no registered media type for ONIX records, so far as I'm aware, but I'll ask Graham Bell at EDItEUR about this, because if one is needed, I guess that he should register it.

I don't have a strong view about the relationship type, but I think that out of courtesy I will ask Graham Bell if he is happy for us to add a relationship type for ONIX. I'm sure he won't mind.

As Caroline has indicated, there are two ONIX namespaces that are relevant in this context:

http://ns.editeur.org/onix/3.0/reference
http://ns.editeur.org/onix/3.0/short

These namespaces refer to the two alternative tag name vocabularies that are available to ONIX implementers. The short tag name schema is preferred in North America, while the reference tag name schema is preferred in Europe and Asia.

Kind regards,

Francis



-----Original Message-----
From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
Sent: 22 November 2015 02:32
To: e-SC34-WG4 at ecma-international.org
Subject: Re: Action item on additional example for Foreign Part in MCE Best Practices document.

Caroline,

Thank you for your contribution!

> 1.  The first paragraph uses both 'foreign part' and 'unknown part.'
> I don't see 'foreign' and 'unknown' as quite synonymous. To me 
> 'foreign' means non-OOXML, but 'unknown' means not understood in some 
> context.  The use of both terms here is a bit confusing. Part 1 uses 
> 'unknown.'.  See Part 1, 9.1.4.  Should we clarify?  Or use 'foreign'
> throughout?

It appears that "foreign part" is never used in ISO/IEC 29500.
We should then use "unknown part" always.

> 2.  Is there any way to declare/register a relationship type that is 
> specific to ONIX or rich metadata?  Chris has just used example.org, 
> which was "established to be used for illustrative examples in 
> documents."  I would be hoping for something more appropriate.  Would 
> it be reasonable to use the same host as Editeur uses for ONIX 
> namespace URLs - which don't resolve?  An example of an ONIX namespace
> URI: is http://ns.editeur.org/onix/3.0/short

We have to define a relationship type for ONIX records.  I thought that EPUB
3 provides something similar, but it doesn not. (It rather relies on a predefied relation "onix-record".)

In my understanding, we have not used namespace URIs as relationship types.
So, how about

	http://purl.oclc.org/ooxml/officeDocument/relationships/onix-record

?


> 3.  For a foreign part, is it necessary to make sure there is an 
> appropriate entry in [Content-Types].xml?  If so, that probably needs 
> to be said.

Yes.  Do we have a media type for ONIX records?  I googled but did not find an answer.  Francis?

> 4.  I have to admit to always having been a bit confused by Part 1,
> 15.2.5 Custom XML Data Storage Part and whether that is also a way to 
> get "foreign" data into an OOXML document.  Is that construct worth a 
> mention in this Best Practices TR?

It is another way to put "foreign" data into an OOXML document.
If we encourage the use of this construct, we should mention it.  But, if I'm not mistaken, we don't do so for a non-technical reason.

> 5. This one is for Rex: I was surprised to see "First, we need to add 
> the file to the OPC package:".  The use of "we" seemed odd.

Yes, avoid "we".

> As I
> worked, a several questions came to mind: Attached is my attempt to 
> introduce the second example into subclause 3.5.  Francis: Do you know 
> someone at Editeur? Might they be open to letting us use '
> http://ns.editeur.org/onix', say?  It's only an example, of course, 
> not normative.



Cheers,
Makoto