Re: Clarifying CURIEs [was Re: RDFa - Dublin Core Metadata - [Fwd: Draft of revised version of Expressing DC in X/HTML meta/link elements]] from Ivan Herman on 2007-08-10 (public-rdf-in-xhtml-tf@w3.org from August 2007)

From: Ivan Herman <ivan@w3.org>
Date: Fri, 10 Aug 2007 09:11:09 +0200
To: Niklas Lindström <lindstream@gmail.com>
CC: Mark Birbeck <mark.birbeck@formsplayer.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <46BC0F8D.4040305@w3.org>
Niklas,

I share your uneasiness, and I agree that the acceptance of the
rel="dc.creator" type of mechanism is less clean. But we have to face
realities (and, with all my respect to Ian and eRDF, this has nothing to
do with eRDF!). The fact of the matter is that the

<link rel="dc.copyright" href="blabla"/>

type of markup in HTML pages to include basic DC terms have become very
widespread indeed. To take an example, this is what the W3C home page
uses:-) Of course, those can (and are) understood and interpreted by
GRDDL, but I think it would be a shame if an RDFa processed XHTML file
did not understood those perfectly valid metadata or, as the DCMI
document and mail I forwarded, the DCMI recommendations decided to
ignore RDFa.

Dublin Core is not the only metadata that uses this mechanism. For
example, if I use OpenID, I am supposed to add the following <link>
elements into my HTML header (that I can then use as my OpenID URI):

<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid.delegate"
href="http://ivanherman.pip.verisignlabs.com/" />

It would be a perfectly o.k. to have RDF statements on your page on
openid, but we hit the same traditional data format!

However, there is an alternative to make the pill less bitter. We can:
accept the 'dot notation' as an alternative to the 'coloumn notation' in
the <head> only, ie, essentially for <link> and <meta> elements only.
These would allow RDFa to include the traditional metadata formats.

None of these create any implementation problem. As I am in an
implementation mood these days:-) I could add these features to my
implementation in about 30 minutes (with testing) without any particular
problem, and a change to the alternative above would not be an issue
either. But I do not think ignoring the issue is good for us.

My two pence...

Thanks

Ivan


Niklas Lindström wrote:
> 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
>>
>>

-- 

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 Friday, 10 August 2007 07:11:10 UTC