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

Hello!

This is regarding the alternative mechanisms of a "dot-notation"
shorthand and namespace binding by "schema.*" ("schema-dot"). It
really bakes my noodle. :)

Doesn't this amount to the incorporation of eRDF into RDFa? While that
*may* be fortunate (since eRDF is in use today), something makes me
feel very uneasy about it. I think it introduces a bit of
arbitrariness at the core, which among other things (probably) makes
it harder to learn.

In my opinion, eRDF is a competent but less powerful alternative to
RDFa, with different (though quite overlapping) sets of features and
trade-offs. Although eRDF works with HTML 4.01 and RDFa does not
(right?), which could merit this, I'd still like to stay on the XHTML
side of things. Having the current syntax for CURIEs and namespace
declarations as the only one is a big part of that IMHO.

While having RDFa capable of coexisting with microformats (and eRDF)
is a goal, I see this as legacy compatibility (I would never mix them
if I could avoid it). If needed, GRDDL.

What is left is how to handle e.g.:

    <link rel="dc.creator" href="http://example.org/Fred" />

I felt a little chill thinking about it (reminiscing the issues with
mingling of values in @class when it was the proposed rdf:type
shorthand). Would this lead to the generation of a nonsensical triple
by today's rules? It is of course directly related to the issue of how
to handle non-prefixed names. I have silently discarded it with a
thought like "nah, non-prefixed names will be ignored", but that
hasn't been resolved, has it? Nor what happens when undeclared
prefixes are used?

I think of RDFa as a pristine approach. If reasonable, as mentioned
above, all kinds of things should peacefully coexist without any
meaning to RDFa (hence the exclusion of @class value parsing). But
@rel="dc.creator" is definitely too close to home to be left
unconsidered. As is:

    <link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />

; a mechanism which looks very odd to me in an RDFa context (too
ad-hoc, for one; raising nesting/scope issues as well).

I think I'd prefer if these constructs just aren't meaningful in the
RDFa sense. eRDF is for GRDDL, as I see it.

I am very open to more debate though (and this is a real issue). The
thing to really consider is that if "dot-notation" is interpreted but
the "schema-dot" namespace declaration is *not*, the handling of
undeclared prefix usage is of utmost importance ('schema'..). And if
none is of meaning, how shall non-prefixed values in @rel/@rev work?

(I might actually end up *supporting* this for pragmatic reasons. But
only with a desire to explicitly state that it would be for legacy
reasons and discouraged when authoring new XHTML+RDFa. I'm in need of
more convincing though.)


[Side-note: If non-prefixed names in @rel/@rev *do* mean "default
namespace + name", wouldn't that -- since that namespace is almost
invariably <http://www.w3.org/1999/xhtml> -- lead to inadvertent
references to an unmanaged set of URIs all beginning with
"http://www.w3.org/1999/xhtml"? For this alone, I vote for ignoring
them. Allowing ":somename" - perhaps. At least it would be (more)
intentional. My guess is that many host language namespaces for RDFa
will not also be RDF vocabularies. Predefineds like @rel="alternate"
in (x)html is another thing I think. Are they even concepts prefixed
by the xhtml syntax namespace? That's reasonably another debate
though.]


Best regards,
Niklas



On 8/9/07, Ivan Herman <ivan@w3.org> wrote:
> O.k. That is actually in line with what I said and done. I always
> referred to the value of @rev, @rel, @property, @instanceof as 'sort of'
> qnames, and I think what I meant is (and the way I implemented it) is
> exactly what you say: I split the string at the ':' point, take the left
> part as an index into an associative array ('dictionary' in Python
> speak) and simply concatenate the value with what is on the right hand
> side of ':'. Adding an alternative branch which does that for '.'
> instead of ':' is a piece of cake (and I have already added it to the
> code locally...:-)
>
> However. We clearly would need proper TF resolution on these issues.
>
> Thanks Mark
>
> I.
>
> Mark Birbeck wrote:
> > 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
> >>
> >>
> >
> >
>
> --
>
> 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
>
>

Received on Thursday, 9 August 2007 18:03:09 UTC