Re: Re: Request for two new media types submitted

Cc- while we work out what to ask for.
I kept Bjoern in the look 'cause he might be interested.
I've also added Ralph as he and I had a long POWDER-S media type discussion.

* Phil Archer <> [2008-12-03 10:49+0000]
> As for POWDER-S, the problem is the Semantic Extension  
> ( Yes, a  
> POWDER-S document is a valid OWL ontology - but it's pretty meaningless  
> unless you implement the extension that allows a resource to be an  
> instance of a class based on matching its IRI against one or more  
> regular expressions. Hence the request for a Media type that is specific  
> to POWDER-S.
> Logically, we'd probably go for application/powder-s+rdf+xml or maybe  
> application/pdrs+rdf+xml but that's getting a bit unwieldy (can you have  
> x+y+xml??). And if we were to suggest a new file extension then it would  
> probably be pdrs if that's available.

I think this argument calls for the creation of a media type for every
(non-XSD) DatatypeProperty, which leads to trouble when mixing them in
the same document. I, and I think the world, would be more motivated
by a protocol need for a media type for POWDER-S than by requirements
on the application interpreting the OWLRDF. For the latter, rdf+xml
struck Ralph and myself as sufficient and consistent with the expected
use of RDF and OWL.

Minor nit:
  We extend RDF with the datatype properties ...
]] —

would imply to me that the RDF machinery must be extended, as opposed
to the application interpreting the RDF graph. Maybe something like:
"POWDER-S uses an <a href="">OWL DatatypeProperty</a> to relate a resource to a regular expression which that resource matches. While POWDER-S uses OWL classes to group resources, any engine determining if a resource belonged in one of these OWL classes would need to be able to test a resource against a regular expression."

Keep going, brave soldier; some day we'll stop harassing you.

> Thanks
> Phil.
> Eric Prud'hommeaux wrote:
>> * Bjoern Hoehrmann <> [2008-12-02 18:36+0100]
>>> * Phil Archer wrote:
>>>> On behalf of the W3C POWDER Working Group I have have today 
>>>> submitted two registration requests for Media Types. As cited in 
>>>> those requests, the key documentation is section 4 of Protocol for 
>>>> Web Description Resources (POWDER): Description Resources [1]. 
>>>> Although this is formally published as a working draft, we are 
>>>> close to reaching our Candidate Recommendation exit criteria and 
>>>> therefore expect to seek transition to Proposed Recommendation 
>>>> later this month.
>>>> [1]
>>> As per RFC 4288
>>>    As stated previously, standards tree registrations for media types
>>>    defined in documents produced by other standards bodies MUST be
>>>    described by a formal standards specification produced by that body.
>>>    Such specifications MUST contain an appropriate media type
>>>    registration template taken from Section 10.
>>> I could not find such a template in the document. Also, given that
>>> some in the W3C think
>>>   In general, a representation provider SHOULD NOT assign Internet
>>>   media types beginning with "text/" to XML representations.
>>> A registration request for text/powder+xml from the W3C should not
>>> come without some form of justification for this choice.
>> Phil, meet Bjoern. Bjoern is lint for W3C and IETF specs.
>> I propose that POWDER register application/powder+xml for POWDER, and
>> use application/rdf+xml for POWDER-S.
>> I think it's handy to include the media type registration in the spec,
>> à al .
>> Following , and
>> assuming you have no preference above being good netizens, I have
>> created a template for both (powder+xml and powder-s+xml) with
>> trumping
>> , i.e. using application/ instead of text/:
>> [[
>> Type name:
>>   application
>> Subtype name:
>>   powder+xml
>> Required parameters:
>>   None
>> Optional parameters:
>>   "charset": This parameter has identical semantics to the charset
>>              parameter of the "application/xml" media type as
>>              specified in [RFC3023], section 3.2.
>> Encoding considerations:
>>   Identical to those of "application/xml" as specified in [RFC3023],
>>   section 3.2.
>> Security considerations:
>>   POWDER is used to make assertions, sometimes socially sensitive,
>>   about web resources. Consumers of POWDER should be aware of the
>>   source and chain of custody of this data. Security considerations
>>   for URIs (Section 7 of [RFC3986]) and IRIs (Section 8 of [RFC3987])
>>   apply to the extent that describing resources in POWDER may prompt
>>   consumers to retrieve those resources.
>> Interoperability considerations:
>>   There are no known interoperability issues.
>> Published specification:
>> Applications which use this media type:
>>   No known applications currently use this media type.
>> Additional information:
>> Magic number(s):
>>   As specified for "application/xml" in [RFC3023], section 3.2.
>> File extension(s):
>>   ".srx"
>> Fragment identifiers:
>>   Identical to that of "application/xml" as described in RFC 3023
>>   [RFC3023], section 5.
>> Base URI:
>>   As specified in [RFC3023], section 6.
>> Macintosh file type code(s):
>>   "TEXT"
>> Person & email address to contact for further information:
>>   Phil Archer <>
>> Intended usage:
>> Restrictions on usage:
>>   None
>> Author/Change controller:
>>   The POWDER specification is a work product of the World Wide Web
>>   Consortium's Protocol for Web Description Resources (POWDER) Working
>>   Group. The W3C has change control over these specifications.
>> References
>> [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
>>           RFC 3023, January 2001.
>> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>>           Resource Identifier (URI): Generic Syntax", STD 66, RFC
>>           3986, January 2005.
>> [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
>>           Identifiers (IRIs)", RFC 3987, January 2005.
>> ]]
> -- 
> Phil Archer
> w.


office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Monday, 8 December 2008 15:31:27 UTC