Nabble - w3.org - www-rdf-comments

Re: Why is xml:lang not allowed on typed literals?

2009-10-15T04:12:16Z

On Thu, 15 Oct 2009, Bernard Vatant wrote:

> Hi all
>
> This list does not seem very active, but hopefully someone is still
> monitoring it and will be able to answer
>
> In
> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal I
> read
>
> Plain literals have a lexical
> form<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-lexical-form>and
> optionally a language
> tag as defined by
> [RFC-3066<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#ref-rfc-3066>],
> normalized to lowercase.
>
> Typed literals have a lexical
> form<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-lexical-form>and
> a datatype
> URI being an RDF URI
> reference<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-URI-reference>
> .
>
> Between the lines I read that the language tag xml:lang is not allowed on
> typed literals. Actually I just tried to do this. The rationale is to define
> a datatype "One Sentence" which must contain a single sentence, starting
> with a upper-case, ending with a dot etc ... and using this datatype for a
> "tagLine" property - which of course has also a language.
>
> So I tried the syntax below and proposed it to various tools
>
> - W3C validator validates it, seems to ignore the xml:lang tag
>
> - Prot?g? does the same, imports the file and ignores the xml:lang tag when
> saving
>
> - SWOOP does the other way round, ignores the rdf:datatype but keeps the
> language tag.
>
> My question is, just out of curiosity, what is the rationale behind not
> allowing xml:lang on typed literals?
>
> Thanks for any clue

I believe the rationale was along the lines that if the value of a typed
literal was represented by an XML construction, the xml:lang belonged _in_
the representation, not _on_ it. That is, that if a literal's values are
represented in infoset terms, the xlm:lang belongs in the representation.

--
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 http://ioctl.org/jan/
Usenet: The separation of content AND presentation - simultaneously.

Why is xml:lang not allowed on typed literals?

2009-10-15T04:03:46Z

Hi all

This list does not seem very active, but hopefully someone is still monitoring it and will be able to answer

In http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Graph-Literal I read

Plain literals have a lexical form and optionally a language tag as defined by [RFC-3066], normalized to lowercase.

Typed literals have a lexical form and a datatype URI being an RDF URI reference.

Between the lines I read that the language tag xml:lang is not allowed on typed literals. Actually I just tried to do this. The rationale is to define a datatype "One Sentence" which must contain a single sentence, starting with a upper-case, ending with a dot etc ... and using this datatype for a "tagLine" property - which of course has also a language.

So I tried the syntax below and proposed it to various tools

- W3C validator validates it, seems to ignore the xml:lang tag

- Protégé does the same, imports the file and ignores the xml:lang tag when saving

- SWOOP does the other way round, ignores the rdf:datatype but keeps the language tag.

My question is, just out of curiosity, what is the rationale behind not allowing xml:lang on typed literals?

Thanks for any clue

Bernard

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:voc="http://example.org/voc#">

            <rdf:Description rdf:about="http://products.example.org/widgets/EBSW">
                <rdfs:label xml:lang="en">Example Best Super Widget</rdfs:label>
                <voc:tagLine xml:lang="fr" rdf:datatype="http://example.org/datatype#OneSentence">Notre meilleur widget est le plus beau et le moins cher du monde.</voc:tagLine>
            </rdf:Description>

</rdf:RDF>

--
Bernard Vatant
Senior Consultant
Vocabulary & Data Engineering
Tel: +33 (0) 971 488 459
Mail: bernard.vatant@...
----------------------------------------------------
Mondeca
3, cité Nollez 75018 Paris France
Web: http://www.mondeca.com
Blog: http://mondeca.wordpress.com
----------------------------------------------------

About a small problem in the RDF Semantics document

2009-10-12T23:50:07Z

Inside the latest version of RDF Semantics document, in Sec.4.4 RDFS Entailment, there is a line says:

Since every rdfs-interpretation is an rdf-interpretation, if S rdfs-entails E then it rdf-entails E;

I think this line should be:

Since every rdfs-interpretation is an rdf-interpretation, if S rdf-entails E then it rdfs-entails E;

I don't know if this is a known problem or not. Thanks.

Robert Lu

RDF Open Questions

2009-04-06T13:35:27Z

What are the open questions need to be answered for RDF. What issues havent been solved yet? Any ideas?

Empty property elements and rdfms-empty-property-elements/test013 test case

2009-03-27T02:44:24Z

Hello all,

I have one comment about the test case "test013" of the
"rdfms-empty-property-elements".
According to the "Empty property elements" section of the RDF/ XML
syntax [1], the "rdf:resource", when used in a property element, is a
shortcut for an "object node which has no further predicate arcs".
However, I think this is in contradiction with the "RDFMS paragraphs
229-234" [2].

As illustrated by the test013 test case, the node
"http://random.ioctl.org/#foo" is used as object of the first predicate,
then subject for another one.
That is to say:
<rdf:Description rdf:about="http://random.ioctl.org/#bar">
<random:someProperty rdf:resource="http://random.ioctl.org/#foo"
random:prop2="baz" />
</rdf:Description>

is expanded as follow (in NTriples notation):

<http://random.ioctl.org/#bar> <http://random.ioctl.org/#someProperty>
<http://random.ioctl.org/#foo> .
<http://random.ioctl.org/#foo> <http://random.ioctl.org/#prop2> "baz" .

best regards,
Thierry Boileau

[1]
http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-empty-property-elements
[2]
http://lists.w3.org/Archives/Public/www-archive/2001Jun/att-0021/00-part#229

Re: Bug in references to XML and Unicode

2009-02-05T01:29:10Z

Dear Bijan,

thank you. The entry has been entered into the official RDF errata document:

http://www.w3.org/2001/sw/RDFCore/errata

Cheers

Ivan

--------------- You wrote --------------------------------

We believe that the hard coded references to XML 1.0 version 2 in:
http://www.w3.org/TR/rdf-syntax-grammar/
and
http://www.w3.org/TR/rdf-concepts/

and to Unicode 3.0 in
http://www.w3.org/TR/rdf-syntax-grammar/
and
http://www.w3.org/TR/rdf-concepts/

are unduly restrictive. We believe that they should normatively refer
to the generically latest versions of both standards.

Implementations that do not wish to update to the latest versions of
those standard could indicate their conformance profile by saying
"Supports RDF(RDF/XML) with Unicode 3.0 and XML 1.0 version 2". Since,
technically speaking, such implementations must reject documents
or models which, e.g., use characters only in Unicode 5.0 this
conformance message seems reasonable. It also frees implementations
to be conforming while accepting extended documents.

If we have missed other places with hard code references to particular
versions of XML and Unicode, we think they should be updated too.

Cheers,
Bijan Parsia, on behalf of the OWL working group.

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (4K) Download Attachment

Re: Problem with rdf:XMLLiteral

2009-01-30T02:09:42Z

Jos,

thanks for your RDF error report. The text, and a reference to the mail,
has been added as:

http://www.w3.org/2001/sw/RDFCore/errata.html#concept-xmlliteral

Thanks again

Ivan

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (4K) Download Attachment

RE: Bug in references to XML and Unicode

2009-01-28T12:55:50Z

I have forgotten the rationale for this restriction.
I believe it arose from a joint meeting RDF Core and I18N in Cannes in 2002 ?
(in the bar IIRC)

Jeremy

> -----Original Message-----
> From: Bijan Parsia [mailto:bparsia@...]
> Sent: Wednesday, January 28, 2009 11:46 AM
> To: Ivan Herman; www-rdf-comments@...
> Cc: Jeremy Carroll; Felix Sasaki; Martin Duerst
> Subject: Bug in references to XML and Unicode
>
> We believe that the hard coded references to XML 1.0 version 2 in:
> http://www.w3.org/TR/rdf-syntax-grammar/
> and
> http://www.w3.org/TR/rdf-concepts/
>
> and to Unicode 3.0 in
> http://www.w3.org/TR/rdf-syntax-grammar/
> and
> http://www.w3.org/TR/rdf-concepts/
>
> are unduly restrictive. We believe that they should normatively refer
> to the generically latest versions of both standards.
>
> Implementations that do not wish to update to the latest versions of
> those standard could indicate their conformance profile by saying
> "Supports RDF(RDF/XML) with Unicode 3.0 and XML 1.0 version 2". Since,
> technically speaking, such implementations must reject documents
> or models which, e.g., use characters only in Unicode 5.0 this
> conformance message seems reasonable. It also frees implementations
> to be conforming while accepting extended documents.
>
> If we have missed other places with hard code references to particular
> versions of XML and Unicode, we think they should be updated too.
>
> Cheers,
> Bijan Parsia, on behalf of the OWL working group.
>
> P.S., CCed to interested parties suggested by Ivan Herman.

Bug in references to XML and Unicode

2009-01-28T11:43:34Z

We believe that the hard coded references to XML 1.0 version 2 in:
http://www.w3.org/TR/rdf-syntax-grammar/
and
http://www.w3.org/TR/rdf-concepts/

and to Unicode 3.0 in
http://www.w3.org/TR/rdf-syntax-grammar/
and
http://www.w3.org/TR/rdf-concepts/

are unduly restrictive. We believe that they should normatively refer
to the generically latest versions of both standards.

Implementations that do not wish to update to the latest versions of
those standard could indicate their conformance profile by saying
"Supports RDF(RDF/XML) with Unicode 3.0 and XML 1.0 version 2". Since,
technically speaking, such implementations must reject documents
or models which, e.g., use characters only in Unicode 5.0 this
conformance message seems reasonable. It also frees implementations
to be conforming while accepting extended documents.

If we have missed other places with hard code references to particular
versions of XML and Unicode, we think they should be updated too.

Cheers,
Bijan Parsia, on behalf of the OWL working group.

P.S., CCed to interested parties suggested by Ivan Herman.

Problem with rdf:XMLLiteral

2009-01-23T05:50:14Z

Hello,

I believe there is an error in the RDF concepts document.
The problem is in the definition of the XMLLiteral datatype [1]; the
value space is ambiguous: it is defined to be disjoint from the value
space of the XML schema datatypes, but does not say anything about other
datatypes. It is therefore unclear whether there is overlap between the
value space of XMLLiteral and, for example, the new datatype rdf:text.
This is a problem for any language relying on this datatype, in
particular, RIF and OWL 2.

Consider, for example, the statement

"<bla>"^^rdf:XMLLiteral = "123@en"^^rdf:text

it is possible to decide whether this statement should hold or not,
i.e., whether is it derived from the empty rule set/ontology.

I propose to add the following text to the RDF errata document [3].

=======================
The following text, in the second bullet of the subheading "The value
space" of Section 5.1 of the RDF Concepts document:

disjoint from the value space of any XML schema datatype [XML-SCHEMA2]

should be replaced by:

disjoint from the value space of any other present or future
datatype (e.g., XML schema [XML-SCHEMA2]), with the exception of future
sub- or supertypes of this datatype

The reason for the replacement is that the definition was ambiguous: the
relationship between the value space of rdf:XMLLiteral and the value
spaces of datatypes not defined in the 2001 version of XML Schema (e.g.,
rdf:text) is unclear. For example, one cannot infer from the
specifications whether there is overlap between the value spaces.
=======================

[1] http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral
[2] http://www.w3.org/2001/sw/RDFCore/errata

smime.p7s (4K) Download Attachment

Re: translation of RDF Primer W3C Reccomendation

2008-12-15T01:11:08Z

On Sat, 13 Dec 2008 17:55:51 +0100, Marco Tibaldeschi
<marco@...> wrote:

> Hello to everyone,
>
> this is Marco Tibaldeschi writing from Italy. I'd like to translate
> the W3C Reccomendation RDF Primer, reachable at
> http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
>
> Is there any problem?
>
> Thanks a lot,
> Marco Tibaldeschi
>
> --
> Marco Tibaldeschi
> gsm: +39.328.4750036
> mail: marco@...
> Alessandria - Italy

Hello Marco

Thanks for writing.

No problem at all with your starting the translation in Italian of the RDF
Primer. It doesn't exist yet in Italian, cf.
<http://www.w3.org/2005/11/Translations/Query?titleMatch=rdf+primer&lang=any&search1=Submit>

--
Coralie Mercier W3C Communications Team mailto:coralie@...
World Wide Web Consortium - http://www.w3.org
ERCIM/W3C - N112 - 2004, rte des lucioles - 06560 Sophia Antipolis - FR
T:+33(0)492387590 F:+33(0)492387822 http://www.w3.org/People/CMercier/

translation of RDF Primer W3C Reccomendation

2008-12-13T08:55:51Z

Hello to everyone,

this is Marco Tibaldeschi writing from Italy. I'd like to translate
the W3C Reccomendation RDF Primer, reachable at
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

Is there any problem?

Thanks a lot,
Marco Tibaldeschi

--
Marco Tibaldeschi
gsm: +39.328.4750036
mail: marco@...
Alessandria - Italy

File Your Claims

2008-11-24T06:14:09Z

£1,350,000.00 pounds has been won by your E-MAIL Address in our IRISH ELECTRONICS SEASONAL AWARD 2008. Do get back to this office with your requirement such to (parris.0101@...) with your

Names :..................
Address :.................
Country :.................
Phone No :...............
Occupation:..............

Minor typo in rdf-syntax-grammar

2008-10-12T02:16:48Z

Hi,

There is a minor typo in the recommandation "RDF/XML Syntax
Specification (Revised)", in section 2.3 "Multiple Property Elements".

The explanation before example 4 currently reads:

"The subject node with URI reference
http://www.w3.org/TR/rdf-syntax-grammar has property elements ex:editor
and ex:title"

but according to the content of example 4, it should probably be
"dc:title" instead of "ex:title" (or the example should instead use
"ex:title", depending on which solution you prefer...)

Regards,
--
Florian,
http://openweb.eu.org/
http://www.linux-france.org/

Typo in RDF/XML Syntax Specification

2008-09-24T21:15:47Z

Hi,

I'd like to report a minor error in
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

Appendix A: Proofs of Lemmas (Informative)
Argument forms table
Derivation #2

rdfs:type rdfs:range rdfs:Class => rdf:type rdfs:range rdfs:Class

_______________________________________________________________
Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]

Re: The status document for the RDF Model and Syntax Specification

2008-08-29T11:58:42Z

At 10:16 PM 8/20/2008 +0300, Airi Salminen wrote:
>In comparing the RDF Recommendation published in February 1999 and the RDF
>Recommendation documents published in February 2004 I came to the status
>document at http://www.w3.org/1999/.status/REC-rdf-syntax-19990222/status.
...
>the six links lead to the corresponding Proposed Recommendations dated in
>15 December 2003, not to the corresponding Recommendations dated in 10
>February 2004.

Thank you for pointing out this mistake, Airi. I have corrected the page.

Regards,
Ralph Swick
W3C/MIT

The status document for the RDF Model and Syntax Specification

2008-08-20T12:16:06Z

Hi!

In comparing the RDF Recommendation published in February 1999 and the RDF
Recommendation documents published in February 2004 I came to the status
document at http://www.w3.org/1999/.status/REC-rdf-syntax-19990222/status.
In the document it is slightly misleading that in the 2004-02-10 dated
note telling

"This W3C Recommendation has been superceded by set of six documents
(Primer, Concepts, Syntax, Semantics, Vocabulary, and Test Cases) jointly
describing updates to the syntax and a more detailed model."

the six links lead to the corresponding Proposed Recommendations dated in
15 December 2003, not to the corresponding Recommendations dated in 10
February 2004. This is a very minor issue but requires from the reader
clicking the Newest Version link of each document to reach the
corresponding
Recommendation documents.

Best regards,

Airi Salminen

--
Airi Salminen, Professor
Department of Computer Science and Information Systems
P.O. Box 35
FI-40014 University of Jyväskylä
Finland
airi.salminen@...
gsm: +358-50-5186284
office phone: +358-14-2603031
http://www.cs.jyu.fi/~airi/

Error in: RDF/XML Syntax Specification (Revised)

2008-08-07T05:19:33Z

Incorrect call to Element Event accessor "string-value"

In section 7.2.19, the Production grammar, the following is found in Production
parseTypeCollectionPropertyElt:

//
For each event n in s and the corresponding element event f in l, the following
statement is added to the graph:

n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> f.string-value
..
//

The last statement is incorrect because f is an Element Event, which contains no
accessor called 'string-value.' Regardless, the correct call should be:
f.subject.string-value, resulting in the following triple being added to the
graph:

//
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#first>
f.subject.string-value .
//

Minor error in RDF Concepts

2008-03-13T05:36:27Z

In the Table of Contents of the RDF Concepts document [1], the heading
for section 2.2.6 says:

Anyone Can Make Statments About Any Resource

Oddly enough, the actual heading is correct.

Regards,

Mark

[1] <http://www.w3.org/TR/rdf-concepts/>

--
Mark Birbeck

mark.birbeck@... | +44 (0) 20 7689 9232
http://www.x-port.net | http://internet-apps.blogspot.com

x-port.net Ltd. is registered in England and Wales, number 03730711
The registered office is at:

2nd Floor
Titchfield House
69-85 Tabernacle Street
London
EC2A 4RR

RDF query

2008-03-06T06:40:16Z

Hi everyone,

I am quite new to this RDF. I am currently working on a project which involves RDF. I wanted to know if there is any software or query language which can query RDF/XML files in XML.
What I mean here is the syntactic constructs of the query language should be in XML,i.e, I should be able to write the queries in XML.
Hope to hear from you guys soon.

Thank you,

Regards.

Re: NTC tool issues fixed

2008-01-22T23:59:12Z

On Tue, 22 Jan 2008, Mark Wallace wrote:

> I recently downloaded the NTC tool referenced in the "RDF Test Cases" document
> (http://www.w3.org/TR/rdf-testcases/). I found two issues that I have fixed:
>
> 1. It did not handle XML typed literals in N-TRIPLE files (e.g.
> "UDP"^^<http://www.w3.org/2001/XMLSchema#string>)
> 2. It would not open the second file properly when compiled with g++
> on Cygwin.
>
> Now that I have made these fixes, I'd like to make them available to the
> larger RDF community, but I don't know how to do that.
>
> Can you give me any advice on how I should proceed?

Patches can be posted here; I'll chase this.

Incidentally, you should note that the algorithm used by NTC is naive;
the one in (for instance) Jena is much smarter in partitioning nodes.

Cheers,
jan

--
jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 http://ioctl.org/jan/

NTC tool issues fixed

2008-01-22T08:35:14Z

I recently downloaded the NTC tool referenced in the "RDF Test Cases"
document (http://www.w3.org/TR/rdf-testcases/). I found two issues that
I have fixed:

1. It did not handle XML typed literals in N-TRIPLE files (e.g.
"UDP"^^<http://www.w3.org/2001/XMLSchema#string>)
2. It would not open the second file properly when compiled with g++
on Cygwin.

Now that I have made these fixes, I'd like to make them available to the
larger RDF community, but I don't know how to do that.

Can you give me any advice on how I should proceed?

--
Mark Wallace
Chief Architect & Ontologist
3 Sigma Research, Indialantic, Florida, USA

Bug in some rdfms-literal-is-xml-structure tests

2007-12-08T12:10:18Z

There are some bugs in some RDF tests at

     http://www.w3.org/2000/10/rdf-tests/rdfcore/
     and in
     http://www.w3.org/2000/10/rdf-tests/rdfcore/latest_All.zip

Namely

     rdfms-literal-is-xml-structure/test002.nt
     rdfms-literal-is-xml-structure/test003.nt
     rdfms-literal-is-xml-structure/test004.nt
     rdfms-literal-is-xml-structure/test005.nt

Have their only RDF statement commented out causing them to be inequivalent to their .rdf counterparts.

--Ifeanyi Echeruo

Share life as it happens with the new Windows Live. Share now!

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T17:01:01Z

Dan Brickley wrote:
>
> My understanding is that text/xml is widely considered problematic,
> eg. http://annevankesteren.nl/2005/03/text-xml
> http://www.w3.org/TR/xhtml-media-types/ quoting from
> http://www.rfc-editor.org/rfc/rfc3023.txt

Tracking down exactly *why* text/* is considered problematic has been
difficult, at least for me, but I think it comes down to 1 ) default
interpretation by the browser, and 2 ) allowed/default encoding, which
you reference above.

From RFC 3023 Section 3:

The top-level media type "text" has some restrictions on MIME
entities and they are described in [RFC2045] and [RFC2046]. In
particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed
(except over HTTP[RFC2616], which uses a MIME-like mechanism). Thus,
if an XML document or external parsed entity is encoded in such
character encoding schemes, it cannot be labeled as text/xml or
text/xml-external-parsed-entity (except for HTTP).

Others (including your first reference above) have also mentioned that
the character set of all text/* entries defaults to US-ASCII if the
charset parameter is not supplied.

Now, if the quoted paragraph from RFC 3023 is true, then there's no more
argument---under no conditions should N3 use a text/* content type. But
I have trouble finding this explicitly in RFC 2045 or RFC 2046. RFC 2046
Section 4.1.2. *does* say that the default for charset "for 'text/plain'
data" is US-ASCII, but to me it is ambiguous whether this applies to
text/* subtypes as well.

I suppose that, with the popular understanding that RFC 2046 requires a
default character set of US-ASCII if there is no charset parameter, then
it's almost as true as if RFC 2046 said so explicitly. But that leads to
uncomfortable conclusions: if nothing but unadorned text should use a
text/* top-level type, and if all text/* top-level types default to
US-ASCII, then I can't think of a single use for the text/* top-level
type---not even for plain text, which should probably be
application/plaintext.

Can't someone just put out another RFC saying that text/* subtypes
besides text/plain may specify default encodings other than US-ASCII, or
something similar? Are we really stuck for the rest of computing
eternity with a specification decision that doesn't even support
Norwegian, much less Mandarin?

You and Graham are making a good argument (well, I guess I brought them
up too on this thread) that old specifications bring gotchas that would
prevent us from using a text/* top-level type for N3. But those reasons
have some larger ramifications which make me uncomfortable.

Garret

P.S. Arg---why do simple decisions have to be so difficult? Damn you,
US-ASCII!

P.P.S. I want a byte to be 32-bits too, while you're at it. ;)

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T16:31:13Z

Garret Wilson wrote:

>
> The following messages seems to be a good overview of some of the
> perceived problems with a text top-level MIME type:
>
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html
>
> Of particular interest is the RFC 2046 requirement that all line breaks
> be CRLF, and that CR and LF not appear outside a line break sequence.
> This doesn't worry me so much---after all, "text/xml" seems to ignore
> this requirement (XML allows arbitrary CRs and LSs; see
> <http://www.w3.org/TR/REC-xml/#sec-line-ends>).

My understanding is that text/xml is widely considered problematic,
eg. http://annevankesteren.nl/2005/03/text-xml
http://www.w3.org/TR/xhtml-media-types/ quoting from
http://www.rfc-editor.org/rfc/rfc3023.txt

Dan

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T16:03:58Z

Graham Klyne wrote:

> Garret Wilson wrote:
>
>>> Funny, I thought that a similar line of reasoning was obvious for
>>> RDF/N3. Let's say that I have a "recipe" format that stores recipes for
>>> my recipe application. Or maybe I have a configuration file type for my
>>> operating system. If they were to have content types of
>>> application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
>>> couldn't I edit them in a general RDF editor that could read N3, even if
>>> I didn't have MyRecipeApplication or MyOSConfigEditor handy?
>>>
>
> Many years ago, my mathematical analysis tutor would say that if a statement was
> "obvious", then either it could be proven in three lines, or it was an
> assumption... ;)
>

I meant "obvious" in a similar light-hearted sense.

> With RDF, the distinction between different uses isn't crystalized in the same
> way.

I'm not sure I follow all the subtle distinctions you're trying to find
between the usability of +xml and +rdf+n3. RDF is more structured and
more self-consistent than XML will ever be; all I know is that I can
take any URF (a framework analogous to RDF) example from
<http://www.urf.name/> and dump it into
<http://www.guiseframework.com/demo/urfprocess> and explore its
structure using a dynamic tree control, regardless of the "different
uses" it might have. If I get an application/recipe+rdf+n3 file, and I
don't have the recipe plugin, it seems "obviously" :) useful to me to be
able to explore its structure. I can always download it if I want to.

Anyway, just an opinion.

Cheers,

Garret

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T15:50:19Z

Garret Wilson wrote:

> Graham Klyne wrote:
>> Also, from RFC 3023 (section 1):
>> [[
>> Similarly, XML will be used as a foundation for other media types,
>> including types in every branch of the IETF media types tree. To
>> facilitate the processing of such types, media types based on XML,
>> but that are not identified using text/xml or application/xml, SHOULD
>> be named using a suffix of '+xml' as described in Section 7. This
>> will allow XML-based tools -- browsers, editors, search engines, and
>> other processors -- to work with all XML-based media types.
>> ]]
>> -- http://www.ietf.org/rfc/rfc3023.txt
>>
>> I don't think a similar case can be made for either RDF or N3 (for
>> different
>> reasons).
>>
>
> Funny, I thought that a similar line of reasoning was obvious for
> RDF/N3. Let's say that I have a "recipe" format that stores recipes for
> my recipe application. Or maybe I have a configuration file type for my
> operating system. If they were to have content types of
> application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
> couldn't I edit them in a general RDF editor that could read N3, even if
> I didn't have MyRecipeApplication or MyOSConfigEditor handy?

Many years ago, my mathematical analysis tutor would say that if a statement was
"obvious", then either it could be proven in three lines, or it was an
assumption... ;)

I can see that you might adopt the position you present above, but I don't think
it's useful to distinguish different uses of RDF in the way that it is for XML.
Different uses of XML, in general, are constrained by different syntactic rules
within the overall framework of XML, and an XML application cannot, in general,
do anything with any XML-based markup language that it hasn't been specifically
constructed to process. Consider: the XML specification itself distinguishes
between "well-formed" and "valid" documents - the "+xml" convention entitles an
application to assume/require a well-formed document and no more but, in some
cases, the full MIME content-type may also dictate validity according to some
schema or DTD.

With RDF, the distinction between different uses isn't crystalized in the same
way. You may choose to keep your recipes in a separate RDF file from, say, the
wine selections that might accompany them. But another application may choose
to write them all into one RDF file -- it's the same RDF language at work here,
not different RDF languages for recipes and wine selection. Thus, I say, just
use application/rdf+xml for both, or if it's not the XML form of RDF you're
using, then use application/n3, or whatever. You could even (legitimately, if
not helpfully) put your OS configuration in the same RDF file as your recipes.

(One might argue that it's possible to define a notion of validity for RDF based
on some additional conditions on vocabulary usage (e.g. a recipe must have both
ingredients and a method of preparation), but such a notion isn't part of RDF.
In the Semantic Web arena, we can use OWL to describe the conditions that allow
for a resource to qualify as a recipe, if one wants a way to express such
constraints, and these apply at the level of the described resource rather than
the data entity containing the description.)

Introducing the +xml convention involved a fair amount of discussion, and I
don't see the point in doing a similar amount of work again unless there's a
clear and obvious (sic) benefit.

#g

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T15:49:15Z

Graham Klyne wrote:
> The person to ask for a more definitive view would be Ned Freed (co-author of
> RFC2046). I have read him argue quite compellingly in a public forum that the
> adoption of text/html was a mistake, because for non-technical users displaying
> the uninterpreted text is just a source of confusion (e.g.
> http://osdir.com/ml/ietf.xml-mime/2000-10/msg00049.html).
>
One of the big issues seems to be the default browser behavior: whether
it should be displayed to the user if no application supports that
content type <http://osdir.com/ml/ietf.xml-mime/2000-10/msg00021.html>.
I can see the arguments on both sides, and it's a tough call. Out of
personal experience, it would irritate me if I were to try to browse to
a DTD file or an RDF/XML file and my browsers tries to download it, when
*I* know that I just wanted to view it on the screen. (Worse still is IE
thinking it can parse the stuff, and then choking because IE isn't
compliant with the specifications, but that's not the fault of the
content type.)

It seems to me that, if you don't have a plugin for N3, then why not
show it on the screen? It's better than nothing, and it doesn't help you
any more if the browser pops up a download dialog. text/rdf+n3 is thus
the lowest common denominator. If it is something that should never be
displayed to the user, then an application/specific+rdf+n3 should be
created, which could still be edited by a general RDF plugin, but would
never be displayed to the user. That's what I'm leaning towards on this,
but it's not an easy call by any means.

Garret

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T14:38:12Z

Graham Klyne wrote:

> Also, from RFC 3023 (section 1):
> [[
> Similarly, XML will be used as a foundation for other media types,
> including types in every branch of the IETF media types tree. To
> facilitate the processing of such types, media types based on XML,
> but that are not identified using text/xml or application/xml, SHOULD
> be named using a suffix of '+xml' as described in Section 7. This
> will allow XML-based tools -- browsers, editors, search engines, and
> other processors -- to work with all XML-based media types.
> ]]
> -- http://www.ietf.org/rfc/rfc3023.txt
>
> I don't think a similar case can be made for either RDF or N3 (for different
> reasons).
>

Funny, I thought that a similar line of reasoning was obvious for
RDF/N3. Let's say that I have a "recipe" format that stores recipes for
my recipe application. Or maybe I have a configuration file type for my
operating system. If they were to have content types of
application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
couldn't I edit them in a general RDF editor that could read N3, even if
I didn't have MyRecipeApplication or MyOSConfigEditor handy?

Garret

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T13:17:10Z

Garret,

The person to ask for a more definitive view would be Ned Freed (co-author of
RFC2046). I have read him argue quite compellingly in a public forum that the
adoption of text/html was a mistake, because for non-technical users displaying
the uninterpreted text is just a source of confusion (e.g.
http://osdir.com/ml/ietf.xml-mime/2000-10/msg00049.html).

Also, look to the mailing list which produced RFC 3023
(http://www.ietf.org/rfc/rfc3023.txt) for the discussion of +xml being something
of a special case. (I think that discussion was also part of the thread I cite
above, but I don't have time to dig deeper right now.)

Also, from RFC 3023 (section 1):
[[
Similarly, XML will be used as a foundation for other media types,
including types in every branch of the IETF media types tree. To
facilitate the processing of such types, media types based on XML,
but that are not identified using text/xml or application/xml, SHOULD
be named using a suffix of '+xml' as described in Section 7. This
will allow XML-based tools -- browsers, editors, search engines, and
other processors -- to work with all XML-based media types.
]]
-- http://www.ietf.org/rfc/rfc3023.txt

I don't think a similar case can be made for either RDF or N3 (for different
reasons).

#g
--

Garret Wilson wrote:

> The following messages seems to be a good overview of some of the
> perceived problems with a text top-level MIME type:
>
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html
>
> Of particular interest is the RFC 2046 requirement that all line breaks
> be CRLF, and that CR and LF not appear outside a line break sequence.
> This doesn't worry me so much---after all, "text/xml" seems to ignore
> this requirement (XML allows arbitrary CRs and LSs; see
> <http://www.w3.org/TR/REC-xml/#sec-line-ends>).
>
> What seems most important to me, however, is that RFC 2046 describes the
> "text" top-level type thus: "Possible subtypes of 'text' thus include
> any word processor format that can be read without resorting to software
> that understands the format" (3.1). This seems to be the defining
> question: can you open and edit the format in a word processor? For N3,
> the answer is yes.
>
> This would lead to the conclusion of "plain N3" using a MIME type of
> text/rdf+n3, as TBL suggested. I would imagine some specific application
> of N3 to use application/app+rdf+n3, where "app" is the name of the
> application that is uses N3 as its underlying format.
>
> Garret
>
> Garret Wilson wrote:
>>
>> When I originally saw that TBL had recommended text/rdf+n3 as the N3
>> MIME type, I was surprised. JSON uses application/json [RFC 4627].
>> XHTML uses application/xhtml+xml [RFC 3236]. text/javascript and
>> text/ecmascript are now marked "obsolete" in favor of
>> application/javascript and application/ecmascript, respectively,
>> noting that, "The use of the 'text' top-level type for this type of
>> content is known to be problematic." [RFC 4329]
>>
>> Looking further on the web, it appears that one of the major concerns
>> is that the character set for "text" content types would default to
>> US_ASCII during HTTP content type negotiation if no "charset"
>> parameter were supplied. However, I read RFC 2046 to say that this
>> only applies to text/plain, and that any future "text" subtypes may
>> specify default character sets other than US_ASCII. But how this is
>> handled in the wild by browsers, I don't know.
>>
>> Whatever the case, there seems to be a trend away from "text" content
>> types (for anything other than text/plain, it seems, which makes me
>> question the usefulness of the entire "text" top-level type, but
>> that's another issue). Are these fears warranted, and should text/* be
>> abandoned in favor of application/*, as Graham suggests? Or will using
>> text/* allow browsers to display the N3 (which seems useful to me) if
>> there is no plugin for N3?
>>
>> Garret
>>
>> Graham Klyne wrote:
>>> Two comments, agreeing text/plain is not ideal...
>>>
>>> 1. My recollection of the IETF discussions around introducing the +xml
>>> convention for MIME content types were focused on applications that
>>> might
>>> recognize the suffix and be able to pass the content to some
>>> application that
>>> could exploit the common framework of XML. I don't think that
>>> applies here.
>>>
>>> 2. The intent of text/... is that the content can be displayed to
>>> human readers
>>> on text display devices and still be reasonably easy to interpret.
>>> It has been
>>> commented that, for example, HTML fails on this score, and
>>> application/ would be
>>> a better choice.
>>>
>>> Which considerations suggest to me application/n3 as an appropriate
>>> MIME content
>>> type.
>>>
>>> #g
>>> --
>>>
>>> Tim Berners-Lee wrote:
>>>
>>>> Comment on "RDF Test Cases".
>>>> W3C Recommendation 10 February 2004
>>>> In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>>>
>>>> The Internet media type / MIME type of N-Triples is text/plain and the
>>>> character encoding is 7-bit US-ASCII.
>>>>
>>>> This is a bug, I think. It prevents crawlers from absorbing the file
>>>> and indexing it proerly, it will prevent the file from being dispatched
>>>> inside a data browser to a data-handling view, and so on.
>>>>
>>>> I would suggest text/rdf+n3 if the assumption is correct that
>>>> NTriples is a subset of N3.
>>>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>>>> possibility would be
>>>> text/rdf=n3; level=nt
>>>> introducing a level parameter to explain what level of N3 was being
>>>> used.
>>>>
>>>> Tim BL
>>>>
>>>>
>>>
>>>
>>
>

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-04T08:57:05Z

The following messages seems to be a good overview of some of the
perceived problems with a text top-level MIME type:

http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html

Of particular interest is the RFC 2046 requirement that all line breaks
be CRLF, and that CR and LF not appear outside a line break sequence.
This doesn't worry me so much---after all, "text/xml" seems to ignore
this requirement (XML allows arbitrary CRs and LSs; see
<http://www.w3.org/TR/REC-xml/#sec-line-ends>).

What seems most important to me, however, is that RFC 2046 describes the
"text" top-level type thus: "Possible subtypes of 'text' thus include
any word processor format that can be read without resorting to software
that understands the format" (3.1). This seems to be the defining
question: can you open and edit the format in a word processor? For N3,
the answer is yes.

This would lead to the conclusion of "plain N3" using a MIME type of
text/rdf+n3, as TBL suggested. I would imagine some specific application
of N3 to use application/app+rdf+n3, where "app" is the name of the
application that is uses N3 as its underlying format.

Garret

Garret Wilson wrote:

>
> When I originally saw that TBL had recommended text/rdf+n3 as the N3
> MIME type, I was surprised. JSON uses application/json [RFC 4627].
> XHTML uses application/xhtml+xml [RFC 3236]. text/javascript and
> text/ecmascript are now marked "obsolete" in favor of
> application/javascript and application/ecmascript, respectively,
> noting that, "The use of the 'text' top-level type for this type of
> content is known to be problematic." [RFC 4329]
>
> Looking further on the web, it appears that one of the major concerns
> is that the character set for "text" content types would default to
> US_ASCII during HTTP content type negotiation if no "charset"
> parameter were supplied. However, I read RFC 2046 to say that this
> only applies to text/plain, and that any future "text" subtypes may
> specify default character sets other than US_ASCII. But how this is
> handled in the wild by browsers, I don't know.
>
> Whatever the case, there seems to be a trend away from "text" content
> types (for anything other than text/plain, it seems, which makes me
> question the usefulness of the entire "text" top-level type, but
> that's another issue). Are these fears warranted, and should text/* be
> abandoned in favor of application/*, as Graham suggests? Or will using
> text/* allow browsers to display the N3 (which seems useful to me) if
> there is no plugin for N3?
>
> Garret
>
> Graham Klyne wrote:
>> Two comments, agreeing text/plain is not ideal...
>>
>> 1. My recollection of the IETF discussions around introducing the +xml
>> convention for MIME content types were focused on applications that
>> might
>> recognize the suffix and be able to pass the content to some
>> application that
>> could exploit the common framework of XML. I don't think that
>> applies here.
>>
>> 2. The intent of text/... is that the content can be displayed to
>> human readers
>> on text display devices and still be reasonably easy to interpret.
>> It has been
>> commented that, for example, HTML fails on this score, and
>> application/ would be
>> a better choice.
>>
>> Which considerations suggest to me application/n3 as an appropriate
>> MIME content
>> type.
>>
>> #g
>> --
>>
>> Tim Berners-Lee wrote:
>>
>>> Comment on "RDF Test Cases".
>>> W3C Recommendation 10 February 2004
>>> In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>>
>>> The Internet media type / MIME type of N-Triples is text/plain and the
>>> character encoding is 7-bit US-ASCII.
>>>
>>> This is a bug, I think. It prevents crawlers from absorbing the file
>>> and indexing it proerly, it will prevent the file from being dispatched
>>> inside a data browser to a data-handling view, and so on.
>>>
>>> I would suggest text/rdf+n3 if the assumption is correct that
>>> NTriples is a subset of N3.
>>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>>> possibility would be
>>> text/rdf=n3; level=nt
>>> introducing a level parameter to explain what level of N3 was being
>>> used.
>>>
>>> Tim BL
>>>
>>>
>>
>>
>

Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

2007-11-03T11:49:23Z

When I originally saw that TBL had recommended text/rdf+n3 as the N3
MIME type, I was surprised. JSON uses application/json [RFC 4627]. XHTML
uses application/xhtml+xml [RFC 3236]. text/javascript and
text/ecmascript are now marked "obsolete" in favor of
application/javascript and application/ecmascript, respectively, noting
that, "The use of the 'text' top-level type for this type of content is
known to be problematic." [RFC 4329]

Looking further on the web, it appears that one of the major concerns is
that the character set for "text" content types would default to
US_ASCII during HTTP content type negotiation if no "charset" parameter
were supplied. However, I read RFC 2046 to say that this only applies to
text/plain, and that any future "text" subtypes may specify default
character sets other than US_ASCII. But how this is handled in the wild
by browsers, I don't know.

Whatever the case, there seems to be a trend away from "text" content
types (for anything other than text/plain, it seems, which makes me
question the usefulness of the entire "text" top-level type, but that's
another issue). Are these fears warranted, and should text/* be
abandoned in favor of application/*, as Graham suggests? Or will using
text/* allow browsers to display the N3 (which seems useful to me) if
there is no plugin for N3?

Garret

Graham Klyne wrote:

> Two comments, agreeing text/plain is not ideal...
>
> 1. My recollection of the IETF discussions around introducing the +xml
> convention for MIME content types were focused on applications that might
> recognize the suffix and be able to pass the content to some application that
> could exploit the common framework of XML. I don't think that applies here.
>
> 2. The intent of text/... is that the content can be displayed to human readers
> on text display devices and still be reasonably easy to interpret. It has been
> commented that, for example, HTML fails on this score, and application/ would be
> a better choice.
>
> Which considerations suggest to me application/n3 as an appropriate MIME content
> type.
>
> #g
> --
>
> Tim Berners-Lee wrote:
>
>> Comment on "RDF Test Cases".
>> W3C Recommendation 10 February 2004
>> In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>
>> The Internet media type / MIME type of N-Triples is text/plain and the
>> character encoding is 7-bit US-ASCII.
>>
>> This is a bug, I think. It prevents crawlers from absorbing the file
>> and indexing it proerly, it will prevent the file from being dispatched
>> inside a data browser to a data-handling view, and so on.
>>
>> I would suggest text/rdf+n3 if the assumption is correct that
>> NTriples is a subset of N3.
>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>> possibility would be
>> text/rdf=n3; level=nt
>> introducing a level parameter to explain what level of N3 was being used.
>>
>> Tim BL
>>
>>
>
>

Re: RDF Test Cases Bug: The N-Triples Grammar is Ambiguous

2007-11-01T05:19:55Z

On 11/1/07, Sean B. Palmer <sean@...> wrote:

> <p:> <> <q:> <> <r:> <> "s" .

Note the following response when we try to get rapper to emit
N-Triples corresponding as closely as possible to this edge case:

$ cat test/rdfxml006.rdf
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="p:> <> <q:> <">
<s xmlns="r:> <" rdf:resource="http://example.org/"/>
</rdf:Description>
</rdf:RDF>

$ rapper -i rdfxml test/rdfxml006.rdf
rapper: Parsing file test/rdfxml006.rdf
<p:\u003E <\u003E <q:\u003E <> <r:\u003E <s> <http://example.org/> .
rapper: Parsing returned 1 triple

rapper refuses to emit an > character in an absoluteURI, even though
according to the specification this cannot be escaped.

All the same, this is the obvious way to correct this problem. It
means that instead of the following:

"These are encoded in N-Triples using the escapes described in section Strings."
- http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#sec-uri-encoding

The specification should instead say something like:

'These are encoded in N-Triples using the escapes described in section
Strings, with the extra proviso that unicode character #x3E, ">", must
be escaped as \u003E.'

This would mean that /[^>]+/ could be used as a regexp to get
absoluteURI production instances.

Thanks,

--
Sean B. Palmer, http://inamidst.com/sbp/

Re: RDF Test Cases Bug: The N-Triples Grammar is Ambiguous

2007-11-01T04:56:34Z

On 11/1/07, Sean B. Palmer <sean@...> wrote:

> As far as I can tell, the N-Triples specification does provide a
> means of interpretation.

That was a typo: I meant of course that it *doesn't* provide a means
of interpretation. I've checked the specification of the EBNF grammar
that is used:

http://www.w3.org/TR/REC-xml/#sec-notation

And it doesn't way whether productions are greedy or not, but clearly
any interpretation would depend on matters such as that, and the fact
that only valid RDF URI references are allowed in the circumstance.

So my test case was as follows:

<p:> <> <q:> <> <r:> <> "s" .

And there are at least four ways of interpreting this:

[<p:> <> <q:> <> <r:>] [<>] ["s"] .
- Greedy, invalid RDF URI references

[<p:> <> <q:> <>] [<r:> <>] ["s"] .
- Greedy and valid RDF URI references

[<p:>] [<> <q:> <> <r:> <>] ["s"] .
- Non-greedy, invalid RDF URI references

[<p:> <>] [<q:> <> <r:> <>] ["s"] .
- Non-greedy, valid RDF URI references

The stakes here are that depending on what the interpretation is, it
mightn't be possible to express various RDF Graphs using N-Triples,
which, as far as I know, is supposed to be able to represent all
possible RDF Graphs.

For example, say we go with the following interpretation:

[<p:> <>] [<q:> <> <r:> <>] ["s"] .

Then how do you express the following?

[<p:> <> <q:> <>] [<r:> <>] ["s"] .

Whatever the resolution, this will undoubtedly make compliant
N-Triples parsing a lot harder than it prima facie appears if parsing
depends on checking whether potential resulting RDF URI references are
valid.

--
Sean B. Palmer, http://inamidst.com/sbp/

RDF Test Cases Bug: The N-Triples Grammar is Ambiguous

2007-11-01T04:35:04Z

According to the N-Triples grammar [1], the following is a valid
instance of the line production in an N-Triples document:

<p:> <> <q:> <> <r:> <> "s" .

But which part of the line matches the subject production, and which
part matches the predicate production? As far as I can tell, the
N-Triples specification does provide a means of interpretation. This
is a very major bug, if so; it means that N-Triples does not have a
usable grammar.

Cf. http://chatlogs.planetrdf.com/swig/2007-11-01.html#T09-28-40

Thanks,

[1] http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntrip_grammar
- RDF Test Cases, 3.1. Extended Backus-Naur Form (EBNF) Grammar

--
Sean B. Palmer, http://inamidst.com/sbp/