Default and empty CURIE prefixes in a non-XHTML host language

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Default and empty CURIE prefixes in a non-XHTML host language

ChristophLange
Dear RDFa developers,

  I am currently specifying the usage of RDFa inside a new host language
(OMDoc, a semantic markup language for mathematical documents;
http://omdoc.org).  I would like to simplify the explanations on CURIEs a bit,
compared to the RDFa syntax recommendation.  In OMDoc as a host language, we'd
like to
1. allow for using the XML default namespace for CURIEs in the default
   namespace, such as :name.
2. define our own vocabulary for CURIEs without prefix and colon.

I suppose both is possible, because the RDFa recommendation says that for
CURIE processing mappings for (1) and (2) have to be provided [by way of the
specification of the host language].  I think I will do that, but not
particularly endorse its usage, as general-purpose RDFa processors would not
understand it.

Now I'm just wondering why this is done in such a strange way for RDFa in
XHTML.  Why are the bare words that _are_ allowed in @rel and @rev
attributes not specified as prefixless CURIEs (mapping to the
http://www.w3.org/1999/xhtml/vocab# namespace) but as special reserved words?
Is this for historical reasons?  And why is there, in addition, a default
namespace http://www.w3.org/1999/xhtml/vocab# for use with the empty prefix?
That makes @rel="next" redundantly equal to @rel=":next".

There is additionally a separate CURIE spec at http://www.w3.org/TR/curie/.
Which one is more reliable, RDFa or CURIE?

Thanks in advance,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Default and empty CURIE prefixes in a non-XHTML host language

Toby Inkster-4
On Thu, 2009-11-26 at 01:17 +0100, Christoph LANGE wrote:
> I suppose both is possible, because the RDFa recommendation says that
> for CURIE processing mappings for (1) and (2) have to be provided [by
> way of the specification of the host language].  I think I will do
> that, but not particularly endorse its usage, as general-purpose RDFa
> processors would not understand it.

Hmmm... this is a good point. I've tried to make my Perl RDFa parser as
generic as possible, and allow XHTML-specific features (like treating
<head> and <body> specially; understanding <base href>; etc) to be
switched off. But I don't currently provide a way to change the default
CURIE prefix from <http://www.w3.org/1999/xhtml/vocab#>.

Nor do I provide a way to define additional keywords. If I were to add
such a feature, what do you think would be more useful - allow
additional keywords in @rel/@rev; or allow them to be used in any
attribute?

> Now I'm just wondering why this is done in such a strange way for RDFa
> in XHTML.  Why are the bare words that _are_ allowed in @rel and @rev
> attributes not specified as prefixless CURIEs (mapping to the
> http://www.w3.org/1999/xhtml/vocab# namespace) but as special reserved
> words? Is this for historical reasons?  

Indeed - it's for hysterical raisins. @rel and @rev are not new
attributes defined by RDFa, but have existed since HTML 2.0 was
published 14 years ago. These keywords have been "grandfathered in" to
RDFa and require slightly different handling to real CURIEs - for
instance, they should be handled case-insensitively, as previous
versions of HTML and XHTML have defined @rel and @rev as
case-insensitive.

> And why is there, in addition, a default
> namespace http://www.w3.org/1999/xhtml/vocab# for use with the empty
> prefix? That makes @rel="next" redundantly equal to @rel=":next".

It does seem a little redundant, yes, but there doesn't seem to be a
better vocabulary to point the empty prefix at.

> There is additionally a separate CURIE spec at
> http://www.w3.org/TR/curie/.
> Which one is more reliable, RDFa or CURIE?

The CURIE spec is a spin-off of the RDFa spec, intended to allow CURIEs
to be easily used by other specifications, like the XHTML role
attribute. The XHTML+RDFa recommendation does not normativly reference
it, so when there are differences between them, the behaviour described
by the XHTML+RDFa recommendation is what RDFa processors should follow.

With the imminent closure of the XHTML2 working group it seems unlikely
that the CURIE spec will ever become a W3C Recommendation, unless it's
taken over by another working group.

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>


Reply | Threaded
Open this post in threaded view
|

Re: Default and empty CURIE prefixes in a non-XHTML host language

ChristophLange
Hi Toby,

  thanks for your helpful comments!

2009-11-26 12:25 Toby Inkster <[hidden email]>:
> Hmmm... this is a good point. I've tried to make my Perl RDFa parser as
> generic as possible, and allow XHTML-specific features (like treating
> <head> and <body> specially; understanding <base href>; etc) to be
> switched off. But I don't currently provide a way to change the default
> CURIE prefix from <http://www.w3.org/1999/xhtml/vocab#>.

Not sure if would already be urgent for you to extend your processor
accordingly.  AFAIK, RDFa has been integrated into XHTML, SVG Tiny,
OpenDocument is in progress, any other language (besides mine)?  Not sure what
requirements OpenDocument has w.r.t. prefixes.  BTW, it seems that on the RDFa
wiki there is currently no collection of host languages that embed RDFa; maybe
it would make sense to start such a list.

> Nor do I provide a way to define additional keywords. If I were to add
> such a feature, what do you think would be more useful - allow
> additional keywords in @rel/@rev; or allow them to be used in any
> attribute?

Allowing such keywords only in @rel/@rev is IMHO too much of an HTML legacy.
I think it would keep the specs cleaner and thus easier to understand and
implement if those keywords were instead implemented as prefixless CURIEs --
and thus also usable in other RDFa attributes.  Why not also have
@typeof="StartPage" (just made up this HTML-like example) where we can have
@rel="next"?

> @rel and @rev are not new attributes defined by RDFa, but have existed since
> HTML 2.0 was published 14 years ago. These keywords have been "grandfathered
> in" to RDFa and require slightly different handling to real CURIEs - for
> instance, they should be handled case-insensitively, as previous versions of
> HTML and XHTML have defined @rel and @rev as case-insensitive.

Oh, I see, I was not aware of that case-insensitivity.  (Is that really the
case?  I don't see any remark on that in the RDFa syntax spec.)  But still,
why that fuss?  The _element_ names in XHTML are not case sensitive either.

> It does seem a little redundant, yes, but there doesn't seem to be a
> better vocabulary to point the empty prefix at.

Indeed, I agree.  Particularly not in XHTML, where the usual _XML_ default
namespace is the one of XHTML, which doesn't make sense to use in RDF
expressions.

But, apropos, that makes me remember XSLT and XPath.  In XSLT 2, one can
specify a default namespace to be used inside XPath expressions, and that
default namespace is independent from the XML default namespace.  This is done
by the @xpath-default-namespace attribute that can occur on any XSLT element
(see http://www.w3.org/TR/xslt20/#standard-attributes).  Analogous to this
would be introducing an additional RDFa attribute @curie-default-namespace;
how about that?

Cheers,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Non-XHTML host languages for RDFa

ChristophLange
Dear all,

  maybe I should ask this again, because it might have got lost in my previous
mail:

2009-11-26 16:25 Christoph LANGE <[hidden email]>:
> Not sure if would already be urgent for you to extend your processor
> accordingly.  AFAIK, RDFa has been integrated into XHTML, SVG Tiny,
> OpenDocument is in progress, any other language (besides mine)?  Not sure
>  what requirements OpenDocument has w.r.t. prefixes.  BTW, it seems that on
>  the RDFa wiki there is currently no collection of host languages that
>  embed RDFa; maybe it would make sense to start such a list.

Do we want to have such an overview?  IMHO it would be interesting to know for
any such host language

* whether it is rather presentation-oriented or rather semantic
* whether it fully integrates RDFa, or some subset of it
* whether it has, besides the RDFa attributes, any additional mechanisms (like
  XHTML's <base/> element) that influence RDFa parsing
* whether/how it interprets CURIEs with no/empty prefix
* whether it has any reserved keywords like "prev"/"next" in XHTML
* what kind of ontologies/metadata vocabularies are predominantly used in RDFa
  annotations in the respective host language?
* …

What do you think?

Cheers,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Toby Inkster-4
On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote:

> Do we want to have such an overview?

I've started a Wiki page outlining known RDFa host languages, plus
significant parsing differences between those and XHTML+RDFa.

http://rdfa.info/wiki/RDFa_Host_Languages

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>



Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Ivan Herman-2
Thanks Toby. These are important information if we work on non-HTML RDFa
in the next incarnation of the RDFa group...

As a comment on your question on SVG 1.2:

[[[
Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be
supported in SVG?
]]]

my answer is: I do not think so. And, actually... SVG1.2 Tiny is a
Recommendation, so I do not believe that question is relevant until (and
if...) the SVG group wants to update SVG1.2 Tiny. Ie, my feeling is
that, in the note, we should make it clear that keywords should not be
recognised in SVG...

I was surprised not to see reference to the same issue for DataRSS. I
must admit I never looked at that spec. Do they accept the xhtml keywords?

Cheers

Ivan

Toby Inkster wrote:
> On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote:
>
>> Do we want to have such an overview?
>
> I've started a Wiki page outlining known RDFa host languages, plus
> significant parsing differences between those and XHTML+RDFa.
>
> http://rdfa.info/wiki/RDFa_Host_Languages
>

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Toby Inkster-4
On Mon, 2009-11-30 at 10:45 +0100, Ivan Herman wrote:

> Thanks Toby. These are important information if we work on non-HTML
> RDFa in the next incarnation of the RDFa group...
>
> As a comment on your question on SVG 1.2:
>
> [[[
> Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be
> supported in SVG?
> ]]]
>
> my answer is: I do not think so. And, actually... SVG1.2 Tiny is a
> Recommendation, so I do not believe that question is relevant until
> (and if...) the SVG group wants to update SVG1.2 Tiny. Ie, my feeling
> is that, in the note, we should make it clear that keywords should not
> be recognised in SVG...

I've done a little more digging into this question. The SVG Tiny 1.2 Rec
says:

        RDFa enforces the further requirement that each value
        string must be a CURIE

Essentially they say "we don't enforce any requirements on the tokens in
this attribute, but RDFa needs them to be CURIEs". However, that's
factually incorrect. There are essentially two questions which emerge:

1. Is rel="next" OK to use in SVG. (I suspect the answer is yes.)

2. What should an RDFa processor do with it? (This is unclear.)

I suspect that the definitive answer should come from the SVG group.

> I was surprised not to see reference to the same issue for DataRSS. I
> must admit I never looked at that spec. Do they accept the xhtml
> keywords?

DataRSS has pretty similar language over their definition of @rel,
saying that it must contain CURIEs. However, unlike SVG Tiny 1.2, they
include a normative reference to the XHTML+RDFa spec. So this seems to
me to be a situation like:

1. Is rel="next" OK to use in DataRSS. (No.)

2. What should an RDFa processor do with it? (Process as per XHTML
+RDFa.)

Another interesting question about DataRSS is, given the following
(example from the "Understanding DataRSS" page of the SearchMonkey
Guide):

<atom:entry>
  <atom:id>http://the.url/in/question</atom:id>
  ...
  <y:adjunct version="1.0" name="com.yahoo.test">
    <y:meta property="tagspace:tags">tag 1 tag2 tag3 tag4</meta>
    <y:item rel="dc:subject" resource="http://photosite.com/img.jpg">
      <y:type typeof="media:Photo">
        <y:meta property="dc:creator">The Nameless One</meta>
      </y:type>
    </y:item>
  </y:adjunct>
</atom:entry>

What is the subject URI of the "tagspace:tags" triple? Should it be
taken from the <atom:id> element?

In version 0.3x of RDF::RDFa::Parser I may well include special support
for Atom, in which if an <atom:entry> element is encountered, a new
subject URI is set to the address given in <atom:id>, or a new bnode if
no <atom:id> child exists.

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>


Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Ivan Herman-2


Toby Inkster wrote:

> On Mon, 2009-11-30 at 10:45 +0100, Ivan Herman wrote:
>> Thanks Toby. These are important information if we work on non-HTML
>> RDFa in the next incarnation of the RDFa group...
>>
>> As a comment on your question on SVG 1.2:
>>
>> [[[
>> Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be
>> supported in SVG?
>> ]]]
>>
>> my answer is: I do not think so. And, actually... SVG1.2 Tiny is a
>> Recommendation, so I do not believe that question is relevant until
>> (and if...) the SVG group wants to update SVG1.2 Tiny. Ie, my feeling
>> is that, in the note, we should make it clear that keywords should not
>> be recognised in SVG...
>
> I've done a little more digging into this question. The SVG Tiny 1.2 Rec
> says:
>
> RDFa enforces the further requirement that each value
> string must be a CURIE
>
> Essentially they say "we don't enforce any requirements on the tokens in
> this attribute, but RDFa needs them to be CURIEs". However, that's
> factually incorrect. There are essentially two questions which emerge:
>
> 1. Is rel="next" OK to use in SVG. (I suspect the answer is yes.)
>
Well...

http://www.w3.org/TR/SVGMobile12/struct.html#RelAttribute

indeed refers to HTML4 and RDFa in their treatment of @rel/@rev. But
they do not seem to define a set of default keywords. My interpretation
is that there is no keywords in SVG's @rel, use 'real' CURIE-s.

> 2. What should an RDFa processor do with it? (This is unclear.)
>
> I suspect that the definitive answer should come from the SVG group.
>

That in any case.

However: if we work on a generic XML+RDFa, we essentially have two
possibilities:

1. we define some sort of a generic mechanism whereby an XML application
language (and maybe even the user!) can define his/her own set of
keywords. This should be compatible with what we have in XHTML+RDFa and
it is then up to the SVG group to decide whether they want to use it or not

2. we scrap the whole mechanism of keywords except for XHTML for
backward compatibility reasons.

I must admit I tempted to go for #2; the only reason we kept the keyword
mechanism in RDFa was for historical reasons only, and I do not see why
this mechanism would have any particular value for other XML dialects
where history is not a factor...

Ivan



>> I was surprised not to see reference to the same issue for DataRSS. I
>> must admit I never looked at that spec. Do they accept the xhtml
>> keywords?
>
> DataRSS has pretty similar language over their definition of @rel,
> saying that it must contain CURIEs. However, unlike SVG Tiny 1.2, they
> include a normative reference to the XHTML+RDFa spec. So this seems to
> me to be a situation like:
>
> 1. Is rel="next" OK to use in DataRSS. (No.)
>
> 2. What should an RDFa processor do with it? (Process as per XHTML
> +RDFa.)
>
> Another interesting question about DataRSS is, given the following
> (example from the "Understanding DataRSS" page of the SearchMonkey
> Guide):
>
> <atom:entry>
>   <atom:id>http://the.url/in/question</atom:id>
>   ...
>   <y:adjunct version="1.0" name="com.yahoo.test">
>     <y:meta property="tagspace:tags">tag 1 tag2 tag3 tag4</meta>
>     <y:item rel="dc:subject" resource="http://photosite.com/img.jpg">
>       <y:type typeof="media:Photo">
>         <y:meta property="dc:creator">The Nameless One</meta>
>       </y:type>
>     </y:item>
>   </y:adjunct>
> </atom:entry>
>
> What is the subject URI of the "tagspace:tags" triple? Should it be
> taken from the <atom:id> element?
>
> In version 0.3x of RDF::RDFa::Parser I may well include special support
> for Atom, in which if an <atom:entry> element is encountered, a new
> subject URI is set to the address given in <atom:id>, or a new bnode if
> no <atom:id> child exists.
>
--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Mark Birbeck-4
Hi Ivan,

> [...]
>
> However: if we work on a generic XML+RDFa, we essentially have two
> possibilities:
>
> 1. we define some sort of a generic mechanism whereby an XML application
> language (and maybe even the user!) can define his/her own set of
> keywords. This should be compatible with what we have in XHTML+RDFa and
> it is then up to the SVG group to decide whether they want to use it or not
>
> 2. we scrap the whole mechanism of keywords except for XHTML for
> backward compatibility reasons.
>
> I must admit I tempted to go for #2; the only reason we kept the keyword
> mechanism in RDFa was for historical reasons only, and I do not see why
> this mechanism would have any particular value for other XML dialects
> where history is not a factor...
>
> [...]

I favour #1. :)

In my view, having short 'tokens' for URIs is the Holy Grail...if we
can get to this point, then RDFa will essentially become an amalgam of
Microformats' ease of use, HTML's ease of deployment, and RDF's
scaleable and decentralised nature.

I discussed some of the advantages of 'tokenising the semantic web' in
a blog post, a while back. Forgive me for quoting myself, but the key
idea is in the middle of the document:


  Whilst it's obviously true that having unqualified values like 'fn'
and 'url' make
  it difficult to bring Microformats into the semantic web, we should be careful
  not to throw the baby out with the bathwater; what may be a weakness in
  terms of scalability, is a strength when it comes to authoring documents.
  Authors need only use simple values in their documents, without having to
  get involved with XML namespaces or other forms of prefix mappings.

  Of course, at some point our dumb machines still need to know how to map
  the token, but it's a lot better to get the machines to do the work, and allow
  authors the freedom of using simple tokens. [1]


My feeling is that we're getting closer to being able to find a
solution to this second step of the problem.

Regards,

Mark

[1] <http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web>

--
Mark Birbeck, webBackplane

[hidden email]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Steven Pemberton-3
On Mon, 30 Nov 2009 14:51:57 +0100, Mark Birbeck  
<[hidden email]> wrote:

> Hi Ivan,
>
>> [...]
>>
>> However: if we work on a generic XML+RDFa, we essentially have two
>> possibilities:
>>
>> 1. we define some sort of a generic mechanism whereby an XML application
>> language (and maybe even the user!) can define his/her own set of
>> keywords. This should be compatible with what we have in XHTML+RDFa and
>> it is then up to the SVG group to decide whether they want to use it or  
>> not
>>
>> 2. we scrap the whole mechanism of keywords except for XHTML for
>> backward compatibility reasons.
>>
>> I must admit I tempted to go for #2; the only reason we kept the keyword
>> mechanism in RDFa was for historical reasons only, and I do not see why
>> this mechanism would have any particular value for other XML dialects
>> where history is not a factor...
>>
>> [...]
>
> I favour #1. :)

In chatting with Ivan, I favour something like:
        take the applicable namespace
        append "/vocab#"
        use that as the missing prefix.

Steven

>
> In my view, having short 'tokens' for URIs is the Holy Grail...if we
> can get to this point, then RDFa will essentially become an amalgam of
> Microformats' ease of use, HTML's ease of deployment, and RDF's
> scaleable and decentralised nature.
>
> I discussed some of the advantages of 'tokenising the semantic web' in
> a blog post, a while back. Forgive me for quoting myself, but the key
> idea is in the middle of the document:
>
>
>   Whilst it's obviously true that having unqualified values like 'fn'
> and 'url' make
>   it difficult to bring Microformats into the semantic web, we should be  
> careful
>   not to throw the baby out with the bathwater; what may be a weakness in
>   terms of scalability, is a strength when it comes to authoring  
> documents.
>   Authors need only use simple values in their documents, without having  
> to
>   get involved with XML namespaces or other forms of prefix mappings.
>
>   Of course, at some point our dumb machines still need to know how to  
> map
>   the token, but it's a lot better to get the machines to do the work,  
> and allow
>   authors the freedom of using simple tokens. [1]
>
>
> My feeling is that we're getting closer to being able to find a
> solution to this second step of the problem.
>
> Regards,
>
> Mark
>
> [1]  
> <http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web>
>
> --
> Mark Birbeck, webBackplane
>
> [hidden email]
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>


Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Shane McCarron


Steven Pemberton wrote:
>
> In chatting with Ivan, I favour something like:
>     take the applicable namespace
>     append "/vocab#"
>     use that as the missing prefix.
In my opinion, something like this would only serve to extend the
confusion between namespaces and vocabularies.  Indeed, we have
purposely avoided doing ANYTHING with the XML default namespace because
it can change throughout a document.  Are you suggesting that the
collection of  'keywords' could morph magically as an XML parser moves
through its content?


--
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

ChristophLange
In reply to this post by Mark Birbeck-4
2009-11-30 14:51 Mark Birbeck <[hidden email]>:

> > 1. we define some sort of a generic mechanism whereby an XML application
> > language (and maybe even the user!) can define his/her own set of
> > keywords. This should be compatible with what we have in XHTML+RDFa and
> > it is then up to the SVG group to decide whether they want to use it or
> > not
>
> In my view, having short 'tokens' for URIs is the Holy Grail...if we
> can get to this point, then RDFa will essentially become an amalgam of
> Microformats' ease of use, HTML's ease of deployment, and RDF's
> scaleable and decentralised nature.
It might be helpful to specify these keywords as a part of an XML schema.
(Note: When I use the lowercase word "schema" I mean the general concept, not
the particular language XML Schema.)  Think of annotating an XML schema by
pointing to classes/properties in an ontology.  Has anything like that ever
been done?

Cheers,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Mark Birbeck-4
Hi Christoph,

> It might be helpful to specify these keywords as a part of an XML schema.
> (Note: When I use the lowercase word "schema" I mean the general concept, not
> the particular language XML Schema.)  Think of annotating an XML schema by
> pointing to classes/properties in an ontology.  Has anything like that ever
> been done?

That's the next step.

Points we've been considering are whether to use @profile to import
these mappings, whether RDFa should be used to describe the mappings,
whether we should map tokens to URIs, or relative paths to URIs,
whether to use OWL, and so on.

All of this is still being discussed.

Speaking only for myself, I'd like to see us come up with a technique
that works in the browser -- which has consequences for the technology
used.

Although it's quite easy to 'import' an external RDFa document, and
import the triples contained within it, you can only do this if the
external document comes from the same domain as the host document.
(Importing simply consists of using a hidden iframe.) So to be able to
import mappings from a central site -- say Yahoo! or Google wanted to
make mappings available for their vocabularies -- we'd need to be able
to use some kind of JSON-based format.

Anyway...as you can see, there are a lot of factors to take into account. :)

Regards,

Mark

--
Mark Birbeck, webBackplane

[hidden email]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Reply | Threaded
Open this post in threaded view
|

Default value for @about depending on language [Re: Non-XHTML host languages for RDFa]

ChristophLange
In reply to this post by Mark Birbeck-4
Dear all,

  one more thought on RDFa in different languages.  Depending on the host
language, it might make sense to allow an RDFa host language to influence the
choice of a subject.  I see a difference between semantic and presentational
languages.  In presentation-oriented languages like XHTML and SVG, the role of
RDFa is allowing for semantic annotations.  One could argue that
semantic-oriented languages don't need RDFa, but for our semantic markup
language OMDoc we actually found RDFa very useful, as it enabled us to reuse a
lot of existing RDF-based metadata vocabularies without inventing further
idiosyncratic markup.

The rule how XHTML+RDFa establishes a new subject, now only considering @about
for simplicity, is that either @about exists on an element, then it defines
the new subject, or the parent subject will be reused.

In OMDoc, however, the situation is different.  There, RDFa metadata are
attached to elements, and the metadata are always metadata of these elements,
and it it recommended to give elements an @xml:id.  Therefore, we have in most
cases the situation

<element xml:id="i" about="#i">
  <meta property="onto:foo" content="bar"/>
  ...
</element>

i.e. a redundant @about attribute that one has to give, as otherwise the RDFa
(according to the XHTML+RDFa parsing rules) would not be parsed correctly.

Comparing that to XHTML+RDFa, where it does not occur that frequently, I could
imagine that the following difference explains this; correct me if I'm wrong:
XHTML is a largely presentation-oriented language, and RDFa in XHTML is used
to present in a human-readable way knowledge whose original location, if any,
is some formalization (imagine the case of using XHTML to render ontologies),
but not the XHTML document.  In host languages that are semantic in itself, I
suppose that, in contrast to XHTML, the things to be annotated are resources
whose original location is the respective XML document.  In the latter case I
think it would make sense to introduce the above-mentioned default mechanism
for the @about attribute.

Note that so far I'm only arguing why this would be good to have in certain
languages.  I have not yet considered all side-effects this has on RDFa's
other ways of establishing a subject.

But what do you think about this in general?

Cheers, and thanks for your feedback,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

ChristophLange
In reply to this post by Mark Birbeck-4
Hi Mark,

  thanks for pointing out the possibilities!

2009-12-01 01:05 Mark Birbeck <[hidden email]>:

> > It might be helpful to specify these keywords as a part of an XML schema.
> > (Note: When I use the lowercase word "schema" I mean the general concept,
> > not the particular language XML Schema.)  Think of annotating an XML
> > schema by pointing to classes/properties in an ontology.  Has anything
> > like that ever been done?
>
> Points we've been considering are whether to use @profile to import
> these mappings, whether RDFa should be used to describe the mappings,
> whether we should map tokens to URIs, or relative paths to URIs,
> whether to use OWL, and so on.
@profile makes a lot of sense to me.  These would then preferably be
profiles describing themselves in RDFa.

Cheers,

Christoph


--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Shane McCarron
I have always liked @profile, but for some reason other groups seem to not like @profile and are planning to remove it from the base language (HTML5).  I imagine we could introduce a new RDFa defined generic attribute for use in RDFa dialects... or just decide we don't care.

Christoph LANGE wrote:
Hi Mark,

  thanks for pointing out the possibilities!

2009-12-01 01:05 Mark Birbeck [hidden email]:
  
It might be helpful to specify these keywords as a part of an XML schema.
(Note: When I use the lowercase word "schema" I mean the general concept,
not the particular language XML Schema.)  Think of annotating an XML
schema by pointing to classes/properties in an ontology.  Has anything
like that ever been done?
      
Points we've been considering are whether to use @profile to import
these mappings, whether RDFa should be used to describe the mappings,
whether we should map tokens to URIs, or relative paths to URIs,
whether to use OWL, and so on.
    

@profile makes a lot of sense to me.  These would then preferably be
profiles describing themselves in RDFa.

Cheers,

Christoph


  

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Default value for @about depending on language [Re: Non-XHTML host languages for RDFa]

Ivan Herman-2
In reply to this post by ChristophLange
Hi Christoph,

I am trying to remember history but my memory is fading with age:-( But
I seem to remember that we did have the similar mechanism on the table
for XHTML using simply @id instead of @xml:id (SVG came fairly late into
the picture when most, if not all, of RDFa was already defined).

AFAIR the issue was the fear of generating unwanted triples (eg, by
breaking the assignment of subject if there is another @about somewhere
up in the tree). Indeed, @xml:id (or @id) could be used for many
different purposes, like internal linking or, in the case of HTML, as a
natural anchor for CSS styling, and the RDFa mechanism may get in the
way. But, I believe, for a general XML language you may have similar
issues. Eg, what if one wants to use such an XML file as an input to
some sort of XSLT processing in future? Just as for CSS, using @xml:id
is a fairly natural anchor point XSLT patterns...

I also have another, slightly more general issue. As you have documented
yourself, there are already some unfortunate differences between
RDFa+XHTML and RDFa+XML. Putting my implementer's hat on, I would love
to make some of those (like the usage or not of xml:base) disappear and
reduce the differences to the strict minimum (essentially to the
existence of head and body and even those differences are questionable
to me). In this sense, I am a bit reluctant to differentiate between
semantic and presentational languages for RDFa...

Anyway. We will have to discuss that, that is for sure!

Thanks

Ivan

Christoph LANGE wrote:

> Dear all,
>
>   one more thought on RDFa in different languages.  Depending on the host
> language, it might make sense to allow an RDFa host language to influence the
> choice of a subject.  I see a difference between semantic and presentational
> languages.  In presentation-oriented languages like XHTML and SVG, the role of
> RDFa is allowing for semantic annotations.  One could argue that
> semantic-oriented languages don't need RDFa, but for our semantic markup
> language OMDoc we actually found RDFa very useful, as it enabled us to reuse a
> lot of existing RDF-based metadata vocabularies without inventing further
> idiosyncratic markup.
>
> The rule how XHTML+RDFa establishes a new subject, now only considering @about
> for simplicity, is that either @about exists on an element, then it defines
> the new subject, or the parent subject will be reused.
>
> In OMDoc, however, the situation is different.  There, RDFa metadata are
> attached to elements, and the metadata are always metadata of these elements,
> and it it recommended to give elements an @xml:id.  Therefore, we have in most
> cases the situation
>
> <element xml:id="i" about="#i">
>   <meta property="onto:foo" content="bar"/>
>   ...
> </element>
>
> i.e. a redundant @about attribute that one has to give, as otherwise the RDFa
> (according to the XHTML+RDFa parsing rules) would not be parsed correctly.
>
> Comparing that to XHTML+RDFa, where it does not occur that frequently, I could
> imagine that the following difference explains this; correct me if I'm wrong:
> XHTML is a largely presentation-oriented language, and RDFa in XHTML is used
> to present in a human-readable way knowledge whose original location, if any,
> is some formalization (imagine the case of using XHTML to render ontologies),
> but not the XHTML document.  In host languages that are semantic in itself, I
> suppose that, in contrast to XHTML, the things to be annotated are resources
> whose original location is the respective XML document.  In the latter case I
> think it would make sense to introduce the above-mentioned default mechanism
> for the @about attribute.
>
> Note that so far I'm only arguing why this would be good to have in certain
> languages.  I have not yet considered all side-effects this has on RDFa's
> other ways of establishing a subject.
>
> But what do you think about this in general?
>
> Cheers, and thanks for your feedback,
>
> Christoph
>
--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Mark Birbeck-4
In reply to this post by ChristophLange
Hi Christoph,

> @profile makes a lot of sense to me.  These would then preferably be
> profiles describing themselves in RDFa.

Right...but as I say, a JavaScript parser running in a browser would
not be able to retrieve those RDFa documents, if they were in a
different domain to the main document.

So even if we do support that, I think we need to do it in a way that
also supports a JSON solution.

Regards,

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Non-XHTML host languages for RDFa

Toby Inkster-4
On Tue, 2009-12-01 at 08:48 +0000, Mark Birbeck wrote:
> Right...but as I say, a JavaScript parser running in a browser would
> not be able to retrieve those RDFa documents, if they were in a
> different domain to the main document.
>
> So even if we do support that, I think we need to do it in a way that
> also supports a JSON solution.

XHR requests are domain-restricted. This is the case whether the
profiles are in XML, XHTML or plain text. JSON doesn't change that.

So called "JSON-P" (which is actually Javascript, not JSON) provides a
workaround, but also opens a gaping security hole as it allows the
server you're reading from to inject arbitrary Javascript code into your
document. If your document contains any private data (e.g. you're using
RDFa on pages containing your company's internal data on a page that's
behind a corporate firewall) then a malevolent JSON-P profile could be
used to steal that data.

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>


Reply | Threaded
Open this post in threaded view
|

Re: Default value for @about depending on language [Re: Non-XHTML host languages for RDFa]

Toby Inkster-4
In reply to this post by ChristophLange
On Tue, 2009-12-01 at 01:09 +0100, Christoph LANGE wrote:
> In OMDoc, however, the situation is different.  There, RDFa metadata
> are attached to elements, and the metadata are always metadata of
> these elements, and it it recommended to give elements an @xml:id.
> Therefore, we have in most cases the situation
>
> <element xml:id="i" about="#i">
>   <meta property="onto:foo" content="bar"/>
>   ...
> </element>

You could always lose the @about attribute and mention in your
documentation that "OMDoc uses RDFa with the following
modifications...".

To be helpful you could provide an XSLT file to transform <element
xml:id="foo"> to <element xml:id="foo" about="#foo">, which would ease
the burden on people wishing to apply generic RDFa processors to OMDoc
documents.

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>


12