Re: Issue http://www.w3.org/2000/03/rdf-tracking/#mime-types-for-rdf-docs

Hi Aaron,

Thanks for this Aaron.  I will of course include a pointer to your draft on the
issues list - I should have done that before, and we should regard this issue as
'active' at the moment.

Reading the original mail mesage that raised the issue, the reason why an RDF
mime type is thought to  be required is to support content negotiation.  Do you
believe that this is the only motivation, or are there others that we should
capture?  The current characterization of the issue in the IL document isn't
very clear.  Would you be able to write some words describing the problem that
could be included there?

How closely related do you feel the #rdfms-fragments issue is to this one. 
Should they be merged and treated as one?

The points that Frank has raised are substantive; I'm not sure that the
rdfms-assertion issue is going to be easy to deal with.  For example, you say
that the 'sender' is asserting any RDF statements 'sent' to be true.  Who is the
sender, e.g. in the case of RDF embedded in your home page?  Your isp?  When
this issue was raised at the rdf-interest f2f, there was a suggestion that such
assertions should have consequences in law, e.g. if they are libelous - how does
one determine exactly what has been said in a way that will work in court? 
These are deep waters.  What do you think of following Frank's suggestion and
separating the mime-type issue from the assertion issue?

On a more general note, are there any other pre-cooked proposals for dealing
with any of the issues that anyone is aware of.

Brian

Aaron Swartz wrote:
> 
> This issue deals with the fact that there is no mime/media type for RDF
> documents. Based on Dan Connoly's rough draft[1] I have drafted a proposed
> resolution to the issue:
> 
> http://blogspace.com/rdf/mimetype
> 
> This draft as been announced to RDF-Interest[2] and featured on XMLhack[3].
> No serious issues have been raised. (Minor ones have been fixed.) Of course,
> the preparation of this draft requires a resolution to certain other issues:
> 
> - What is the fragment syntax for RDF?
>   http://www.w3.org/2000/03/rdf-tracking/#rdfms-fragments
> 
> While I feel it would be a good idea to include a fragment syntax in the
> media type registration, I felt that the RDF community had not come to
> consensus on this issue, so it is not currently included. I'd suggest
> wording close to what TimBL suggests:
> 
>     A fragment "n" in an RDF/XML document "d" refers to the resource d#n
>     as described by the document.
> 
> It's rather vague, but I think it best expresses the intention of RDF.
> 
> - It needs to be clear that an RDF statement is an assertion.
>   http://www.w3.org/2000/03/rdf-tracking/#rdfms-assertion
> 
> As was clear in Dan Connolly's draft[1], it is important that the media type
> specification make this point clear. I have included the wording:
> 
>     Because RDF is a format for semantically-meaningful information, it is
>     important to note that transmission of RDF via HTTP, SMTP or some
>     similar protocol, means that the sender asserts the content of the RDF
>     document.
> 
> - Interoperability Considerations
> 
> Also of interest to the working group will be this section:
> 
>     Interoperability considerations:
>         For maximum interoperability it is recommend that RDF files use the
>         Basic RDF Syntax, since this is most likely to be understood by RDF
>         parsers and remain stable through future RDF specifications. It is
>         also recommended that RDF documents do not use processing
>         instructions, as RDF parsers give no meaning to them.
> 
> Thank you for your comments and consideration of this draft,
> 
> [1] http://www.w3.org/2001/03mr/rdf_mt
> [2] http://lists.w3.org/Archives/Public/www-rdf-interest/2001Apr/0367.html
> [3] http://xmlhack.com/read.php?item=1185
> --
> [ :name "Aaron Swartz" ;
>   :mbox <mailto:me@aaronsw.com> ;
>   :homepage <http://www.aaronsw.com> ] is dc:author of <> .

Received on Wednesday, 2 May 2001 21:40:40 UTC