Re: W3C mailing list search results in RDF

On Wed, Jul 30, 2003 at 09:31:25PM +0100, Graham Klyne wrote:
> Eric,
> 
> I don't think the /n3 vs /vnd.w3c.n3 issue is a big deal.  I just thought 
> using the vnd tree might make registration easier if there isn't a stable 
> specification to point at.
> 
> Hmmm... let's check:
> [[
> 2.1.1.  IETF Tree
> 
>    The IETF tree is intended for types of general interest to the
>    Internet Community. Registration in the IETF tree requires approval
>    by the IESG and publication of the media type registration as some
>    form of RFC.
> ]]
> -- http://www.ietf.org/rfc/rfc2048.txt
> 
> and:
> [[
> 2.1.2.  Vendor Tree
> 
>    The vendor tree is used for media types associated with commercially
>    available products.  "Vendor" or "producer" are construed as
>    equivalent and very broadly in this context.
> 
>    A registration may be placed in the vendor tree by anyone who has
>    need to interchange files associated with the particular product.
>    However, the registration formally belongs to the vendor or
>    organization producing the software or file format.  Changes to the
>    specification will be made at their request, as discussed in
>    subsequent sections.
> 
>    Registrations in the vendor tree will be distinguished by the leading
>    facet "vnd.".  That may be followed, at the discretion of the
>    registration, by either a media type name from a well-known producer
>    (e.g., "vnd.mudpie") or by an IANA-approved designation of the
>    producer's name which is then followed by a media type or product
>    designation (e.g., vnd.bigcompany.funnypictures).
> 
>    While public exposure and review of media types to be registered in
>    the vendor tree is not required, using the ietf-types list for review
>    is strongly encouraged to improve the quality of those
>    specifications. Registrations in the vendor tree may be submitted
>    directly to the IANA.
> ]]
> -- ibid.
> 
> So unless you're requesting publication of the registration (not the 
> specification) as an RFC, the vnd tree may be easier.  In this context, I 
> guess w3c would count as a "producer".

Tim, were you intending to go the RFC route with n3?

> Here's another thing to contemplate:
> [[
> 2.1.5.  Additional Registration Trees
> 
>    From time to time and as required by the community, the IANA may,
>    with the advice and consent of the IESG, create new top-level
>    registration trees.  It is explicitly assumed that these trees may be
>    created for external registration and management by well-known
>    permanent bodies, such as scientific societies for media types
>    specific to the sciences they cover.  In general, the quality of
>    review of specifications for one of these additional registration
>    trees is expected to be equivalent to that which IETF would give to
>    registrations in its own tree. Establishment of these new trees will
>    be announced through RFC publication approved by the IESG.
> ]]
> -- ibid.
> 
> A W3C tree, anyone?   (e.g. application/w3c.n3)
> 
> ...
> 
> (BTW, I forgot to say, great work on the search results!  Now, how to use 
> them?)

tx!

I'm finishing up the implementation of a query language that I will
use as a query interface to the script. This way you can use
predicates to indicate the search parameters instead of CGI
parameters. Of course, the whole search string will be burried in a
CGI parm, but at least you can express arbitrary search criteria
that may not be expressible in the expert query mode. I hope this
shift of burden to the query mechanism doens't hurt too much. We'll
see.

By way of documentation, I can point you at a fairly complex search
example [1] and the grammar [2] and code [3,4] that parse it. I have
a few nits in the grammar to work out (looking for help) and need to
test a federated query scenario before I'll be ready to add support
for algae2 to the search script.

[1] http://dev.w3.org/cvsweb/perl/modules/W3C/Rdf/test/patternTest3.alg
[2] http://dev.w3.org/cvsweb/perl/modules/W3C/Rdf/AlgaeParser.yp
[3] http://dev.w3.org/cvsweb/perl/modules/W3C/Rdf/Algae2.pm
[4] http://dev.w3.org/cvsweb/perl/modules/W3C/Rdf/AlgaeStructure.pm

> #g
> --
> 
> At 15:34 30/07/03 -0400, Eric Prud'hommeaux wrote:
> 
> >On Wed, Jul 30, 2003 at 09:23:51AM +0100, Graham Klyne wrote:
> >> At 18:17 29/07/03 -0400, Eric Prud'hommeaux wrote:
> >> >The mailing list search [1] results are now available in triple
> >> >languages.  The accet header tells it how to render the results. The
> >> >following accept headers are defined:
> >>
> >>    ...
> >>
> >> >  application/n3
> >>
> >>    ...
> >>
> >> Er, has anyone submitted a MIME type registration for application/n3 ?
> >
> >fussy!
> >
> >> It's not listed at:
> >>   http://www.iana.org/assignments/media-types/application/
> >>
> >> (Given N3's not-quite-stable status, maybe application/vnd.w3c.n3 would 
> >be
> >> more appropriate?)
> >>
> >> (Consider this a gentle nudge in the style of, say, Dan Connolly's
> >> exhortations not to use unregistered UIRI schemes ;-)
> >
> >done, but here's why it may change back:
> >
> >Tim told me he had applied for it.
> >I changed it per your suggestion without asking him.
> >I reallized that I was serving them all as text/html do to a thinko. I
> >fixed said thinko and picked application/vnd.w3c.n3 for n3.
> >
> >> #g
> >>
> >>
> >>
> >> ------------------
> >> Graham Klyne
> >> <GK@NineByNine.org>
> >> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> >
> >--
> >-eric
> >
> >office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> >cell:   +1.857.222.5741
> >
> >(eric@w3.org)
> >Feel free to forward this message to any list for any purpose other than
> >email address distribution.
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 30 July 2003 17:18:40 UTC