[Odrl-version2] ODRL Version 2.0 - XML Encoding

[Michael Steidl (IPTC)]

Re sorting out URIs and QNames:
1) how to identify a prefix? The string to the left of a colon? 
2) Then each http URL has a prefix of http
3) By your rule below: as this prefix cannot be resolved using the namespace
declarations the string has to be a URI. Conclusion correct?

Re QCodes:
- they are specified in the scope of the IPTC G2-Standards, that are news
exchange format standards, tailored to the requirements of the news
industry.
- the QCode specs are in chapter 7 of the NewsML-G2 spec document:
http://www.iptc.org/std/NewsML-G2/2.4/specification/NewsML-G2_2.4-spec-PCL.p
df 
- for mapping prefixes (or "alias" in G2) to URIs a <catalog> element is
used in G2, not the XML namespace syntax to allow disambiguation. But
adopting this approach is not a must for adopting QCodes.

Michael


> -----Original Message-----
> From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-
> bounces at odrl.net] On Behalf Of ri at odrl.net
> Sent: Monday, October 25, 2010 3:06 PM
> To: ODRL-Version2
> Subject: Re: [Odrl-version2] ODRL Version 2.0 - XML Encoding
> 
> 
> On 25 Oct 2010, at 20:21, Michael Steidl (IPTC) wrote:
> 
> > The ODRL XML Encoding draft specifies the uid of elements is "URI or
> QName",
> > as a URI can be URN or URL I recommend using http-URLs for the
> examples -
> > much less formal issues with them.
> 
> Sure, I can easily change them over to http identifiers...
> 
> > And I would like to add that the specification "URI or QName" is a
> bit
> > tricky to process: how to make a distinction? The processor on the
> receiving
> > side must know whether the string is a URI or QName as QNames have to
> be
> > resolved to URIs before they are further processed.
> 
> I would imagine that after extracting the prefix, if it matched one of
> the local namespace declarations, then you have a QName, otherwise, it
> is likely to be a URI (as long as it matched http/urn etc and was
> otherwise syntactically correct...)
> 
> 
> > Further I would support Stuart's pointing at a major issue with
> QNames:
> > their local part MUST NOT start with a digit - but there are many,
> many
> > existing vocabularies which have codes/terms which start with a
> digit, the
> > ISBN is a good example.
> 
> In these cases, I would say that you would have to then default to the
> full URI:
>     URN:ISBN:0-395-36341-1
>     http://my.local.bookeseller.com/books/ISBN/0-395-36341-1
> 
> 
> > For that reason the IPTC has specified a QCode which is actually the
> same as
> > a QName, except this lexical space constraint, we invite ODRL to look
> into
> > QCodes.
> 
> Sure, do you have a link about Qcodes?
> 
> Cheers
> 
> Renato Iannella
> ODRL Initiative
> http://odrl.net
> 
> 
> 
> _______________________________________________
> Odrl-version2 mailing list
> Odrl-version2 at odrl.net
> http://odrl.net/mailman/listinfo/odrl-version2_odrl.net