Clarifying CURIEs [was Re: RDFa - Dublin Core Metadata - [Fwd: Draft of revised version of Expressing DC in X/HTML meta/link elements]]

Hi Ivan,

We might as well start another thread. :)

The CURIEs spec is not actually about the square bracket stuff--that's
just a way to disambiguate between a CURIE (compact URI) and a URI.

The idea of CURIEs is that instead of using QNames as a URI
abbreviation syntax, we use something that is specifically designed
for the job. The problem with the definition of 'QName' is that it is
essentially about defining element and attribute names in XML:

  <a:b c:d=:x" />

However, over the years QNames have been used to abbreviate URIs
(RDF/XML) and to namespace various features like functions (XPath) and
data types (XML Schema). At least those uses are inside XML documents,
but the use of QNames in SPARQL is genuinely odd, since it has nothing
to do with XML.

So CURIEs was devised to _look_ much like QNames, but to be a
standalone specification that could be incorporated into other
specifications, and to have as a clear goal URI abbreviation--the use
to which QNames are put in RDF/XML and SPARQL.

Although CURIEs were intended to look much like QNames, the main
difference is that the part that is being qualified is not resticted
by the QName syntax (which was intended for element and attribute
names), thus allowing values like this:

  isbn:0321154991

Of course, that now looks like a URI too, so in any situation where a
CURIE could be mistaken for a URI, it is legitimate to wrap it like
this:

  [isbn:0321154991]

Now, to your other questions.

Once you take the idea of 'abbreviation of URIs' out into a separate
spec like we've done here, you have the possibility of saying that
it's the *mechanism* that we're interested in, and not the syntax. So
we might say that as long as we can find a way to indicate what the
separator is, we don't much care whether CURIEs are expressed like
this:

  a:b

or this:

  a.b

And likewise, since all we're doing with the first part (the prefix)
is substituting a short string for a longer one, we also don't much
care whether we use @xmlns to express the substitution string (as in
XML), a <link> (as in eRDF, and possibly in HTML+RDFa) or a keyword
(as in SPARQL).

The key point is that we now have a way of talking about 'compact
URIs' without getting sucked into the whole confusion surrounding
QNames, and without being limited by its syntax. (Note on this latter
point that recent SPARQL drafts have dropped the use of QNames but
unfortunately haven't used CURIEs.)

Finally, to answer the question of 'where we are at' with CURIEs,
there are drafts available:

  <http://www.w3.org/TR/curie/>

and Bob du Charme referred to it :):

  <http://www.oreillynet.com/xml/blog/2005/10/mark_birbecks_compact_uri_synt.html>

The whole motivation for CURIEs is discussed in detail here:

  <http://internet-apps.blogspot.com/2005/10/curies-compact-uri-syntax-semantic.html>

Regards,

Mark

On 09/08/07, Ivan Herman <ivan@w3.org> wrote:
>
>
> Mark Birbeck wrote:
> > Hi Ivan,
> >
> >>
> >> Personally, I think we should define a @profile.
> >
> > I thought we'd resolved to create a profile, but to make it optional.
> > That allows those who want to be able to say "my document definitely
> > contains RDFa" to do so, at the same time as aloowing those who want
> > to say "I'm going to process every document as if it contains RDFa" to
> > also do so.
> >
>
> I know we had that discussed, I did not realize that is a formal
> decision now. If so, fine!
>
> >
> >> - There is a small remark on the <meta> element. Essentially, the issue
> >> is that @name is used for what we use as @property elsewhere. I wonder
> >> whether it would not be possible (and very simple) to allow for @name as
> >> an alias to @property in the context of a <meta> element and use it
> >> accordingly. This is not unlike what we do with @src for <img>...
> >
> > Both should be allowed already, but I don't think we've ever discussed
> > it. And I know for sure that we've never said what would happen if
> > both attributes were present.
> >
>
> Just as @resource has a higher priority than @href (and @src), I would
> say @property has a higher priority than @name.
>
> >
> >> - The most controversial issue, just raising it (please, do not eat me
> >> alive here). The syntax used in a <link> @rel is the dotted notation.
> >> Ie, dcterm.title. The also use <link> to, essentially, _declare_ those
> >> prefixes.
> >>
> >> We use dcterm:title because, well, we use namespaces. Hm, we use the
> >> _syntax_ of namespaces, but we do _not_ use them in the XML sense,
> >> right? More as a concatenation sense like in RDF. So, well, can we
> >> reconcile these two syntaxes? To be able to handle quite a lot of
> >> information out there in terms of DC already? Or to come?
> >
> > I think you are right. We've discussed a number of different ways to
> > allow support for alternative namespacing mechanisms in the CURIEs
> > syntax, but we haven't nailed any down yet. However, so far in this
> > group the pain of _not_ having CURIEs doesn't seem to have promoted
> > widespread support for it...maybe this is the straw? ;)
> >
>
> I must admit that I am not sure where we stand with CURIE-s at the
> moment, I would be pleased if we could clarify this. For all the
> examples we have, the following seems to work:
>
> - URI-s in the traditional sense for @href, @src, @resource, just as
> XHTML has it
> - sort of namespace/qname for @instanceof, @rel, @rev, ...
>
> I think we all agreed that we do not really need that [_:123] type
> things. My feeling is: we could drop all this [...] notation once and
> for all. I do not see any serious use case; on the other hand, it would
> take away a potentially contentious issue...
>
>
> >
> >> Bear with me:-) I could see the following alternatives:
> >>
> >> - Accept the a.b notation for @rel, @instanceof, @rev, @property, as an
> >> alias to a:b (or a replacement thereof?:-)
> >
> > "As well as", is ok, if we have a way of defining it clearly. As I've
> > argued before though, "replacement" just seems odd--we have a
> > namespacing mechanism in the W3C.
> >
>
> You're right. Let us keep both syntaxes. Ie, in @rel, for example,
> dc.author would mean the same as dc:author. I can happily live with
> this, and would do a lot ot accomodate the DCMI people...
>
>
> >
> >> - Accept the special link notation as, essentially, global namespace
> >> declarations
> >>
>
> What do you think about this?
>
> >> I think we must keep the xmlns notation, because that provides us with
> >> the copy paste facilities. But the others, well...
> >>
> >> Of course, we may ask/hope that the DCMI proposes a namespace-like
> >> notation all the way down. I am not sure that would happen.
> >
> > CURIEs would help here, since they define a namespacing mechanism that
> > stands outside of a document and is independent of languages. (For
> > example, CURIEs can be used by SPARQL.)
> >
>
> Mark, I am lost what you mean by CURIE. Where can CURIE-s be used in SPARQL?
>
> Ivan
>
> > Regards,
> >
> > Mark
> >
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>


-- 
  Mark Birbeck, formsPlayer

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

  standards. innovation.

Received on Thursday, 9 August 2007 14:51:09 UTC