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

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