RDF Namespaces, Fragments, And MIME Types

[[[
05:10:08 <sbp> http://www.openhealth.org/RDDL/tddl
05:10:08 <dc_rdfig> B: http://www.openhealth.org/RDDL/tddl from sbp
05:10:21 <sbp> B:|Terminology Definition Description Language (TDDL)
1.0
05:10:21 <dc_rdfig> titled item B
05:10:32 <sbp> B:A very sensible approach to RDF namespaces, IMO
05:10:32 <dc_rdfig> commented item B
05:11:56 <sbp> It allows us to use XHTML at locations where we want to
say that #blargh can be anything, not just a fragment of markup
05:12:04 <sbp> well, it's not XHTML... that's why
05:14:02 <sbp> Hmm... I might pester Jonathan to develop that further;
I think that all RDF "namespaces" should use it. It's perfect. It was
annoying when I figured out that RDL is unsuitable...
05:14:59 <sbp> then again, TDDL sent as text/html is also unsuitable,
when you think about it. Although I hope that the text/html MIME
specification is sufficiently vague on the subject
05:16:13 <tav> tav has quit
05:16:32 <tav`> tav` has quit
05:16:54 <sbp> [[[
05:16:55 <sbp>    The URI specification [URI] notes that the semantics
of a fragment
05:16:55 <sbp>    identifier (part of a URI after a "#") is a property
of the data
05:16:55 <sbp>    resulting from a retrieval action, and that the
format and
05:16:55 <sbp>    interpretation of fragment identifiers is dependent
on the media type
05:16:55 <sbp>    of the retrieval result.
05:16:57 <sbp>    For documents labeled as text/html, the fragment
identifier
05:16:59 <sbp>    designates the correspondingly named element; any
element may be
05:17:01 <sbp>    named with the "id" attribute, and A, APPLET, FRAME,
IFRAME, IMG and
05:17:03 <sbp>    MAP elements may be named with a "name" attribute.
This is described
05:17:05 <sbp>    in detail in [HTML40] section 12.
05:17:09 <sbp> ]]] - http://www.ietf.org/rfc/rfc2854.txt
05:17:20 <sbp> damnit
05:18:10 <sbp> the one little ray of hope for RDF "namespaces" dashed
by careful wording :-)
05:19:58 <sbp> could do it in XML I suppose. Here's the RFC:
http://www.ietf.org/rfc/rfc2376.txt
05:20:43 <sbp> ugh, it says nothing about fragment identifiers at all!
05:21:12 <sbp> ah, obsoleted by http://www.ietf.org/rfc/rfc3023.txt
05:21:35 <sbp> [[[
05:21:35 <sbp>    Section 4.1 of [RFC2396] notes that the semantics of
a fragment
05:21:35 <sbp>    identifier (the part of a URI after a "#") is a
property of the data
05:21:35 <sbp>    resulting from a retrieval action, and that the
format and
05:21:35 <sbp>    interpretation of fragment identifiers is dependent
on the media type
05:21:36 <sbp>    of the retrieval result.
05:21:39 <sbp>    As of today, no established specifications define
identifiers for XML
05:21:40 <sbp>    media types.  However, a working draft published by
W3C, namely "XML
05:21:42 <sbp>    Pointer Language (XPointer)", attempts to define
fragment identifiers
05:21:44 <sbp>    for text/xml and application/xml.  The current
specification for
05:21:46 <sbp>    XPointer is available at http://www.w3.org/TR/xptr.
05:21:48 <sbp> ]]]
05:22:20 <sbp> I do believe that it should be up to the provider of
the namespace of the root of the document
05:22:43 <sbp> that is, of course, ignoring the ramifications of
XPointer
05:24:00 <SeanP> SeanP has joined #rdfig
05:24:17 <SeanP> SeanP has quit
05:24:22 <sbp> sbp has quit
05:24:29 <sbp> sbp has joined #rdfig
05:25:42 <sbp> well, http://www.w3.org/TR/xptr/#schemes is a bundle of
laughs
05:28:07 <sbp> the wonderful upshot of that is (as far as I read it),
RDF pretty much runs contrary to that. #blargh in an RDF document is
never necessarily a part of the document, and yet XPointer says they
are always "bare names"...
05:28:35 <sbp> Hmm... although it alludes to IDs on that point, it
does not say that it is necessarily an XML ID, or that it represents a
chunk of the document
05:28:55 <sbp> It *may* be possible to carve out a little slice of
happiness for RDF
05:29:49 <oierw`> :)
05:30:05 <sbp> er... xpointer(id('résumé'))
05:30:29 <sbp> always nice to see i18n in a specification :-)
05:30:57 <sbp> #id does map to #xpointer(id('id')), so it's a case of
finding out what the XML specification has to say about it...
05:32:11 <sbp> "ID values must uniquely identify the elements which
bear them" - http://www.w3.org/TR/REC-xml
05:32:43 <sbp> great
05:33:03 <sbp> But XPointer is only in CR, so there is still time...
05:33:16 <tav`> tav` has joined #rdfig
05:34:01 <sbp> "We expect that sufficient feedback to determine its
future will have been received by 4 March 2002. Comments on this
document should be sent to the public mailing list
www-xml-linking-comments@w3.org (archive)." -
http://www.w3.org/TR/xptr/
05:35:23 <sbp> this is the sort of thing that TAG should be watching
out for
05:36:55 <sbp> what I want to do is to be able to define an XML based
language that is independent of RDF, but very much like RDDL in that
it can point to RDF files that define terms in the namespace
05:37:48 <sbp> XML styled with CSS will do, although XHTML would have
been preferable... the text/html MIME type just forbids HTML talking
about anything other than itself. HTML is so egocentric :-)
05:38:16 <sbp> I mean that the fragments when interepreted on an HTML
document necesserily refer to a part of that document
05:38:40 <sbp> * sbp realises that he's only writing these notes for
himself, so may as well use email to www-archive... oh, well
05:39:19 <sbp> XML is a close call... XPointer is reserving a whole
lot of stuff, and I don't think that is compatable with RDF. It's also
incompatable for this neutral namespace language
05:40:16 <sbp> of course, the namespace language should probably also
be able to say things about the terms in the namespace... in fact, it
must be able to. So it'll be a language which has a 1 to 1 mapping
with an RDF graph, but will not be as expressive as XML RDF, and
certainly not as expressive as NTriples
05:40:41 <sbp> * sbp decides to bundle this up to www-archive
]]] - http://ilrt.org/discovery/chatlogs/rdfig/2001-12-03.txt

Cheers,

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Monday, 3 December 2001 00:42:03 UTC