Nabble - w3.org - public-rdf-in-xhtml-tf

RDFa TF Meeting minutes of 2009-12-03

2009-12-03T11:02:07Z

Minutes are at:

http://www.w3.org/2009/12/03-rdfa-minutes.html

text version below.

Ivan

[1]W3C

[1] http://www.w3.org/

RDFa in XHTML Task Force

03 Dec 2009

[2]Agenda

[2]
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Dec/0026.html

Previous: [3]http://www.w3.org/2009/11/19-rdfa-minutes.html

[3] http://www.w3.org/2009/11/19-rdfa-minutes.html

See also: [4]IRC log

[4] http://www.w3.org/2009/12/03-rdfa-irc

Attendees

Present
Manu Sporny, Mark Birbeck, Shane McCarron, Ivan Herman,
Steven Pemberton

Regrets
Ben Adida

Chair
Manu Sporny

Scribe
manu

Contents

* [5]Topics
1. [6]Action Items
2. [7]RDFa WG charter status
3. [8]@vocab discussion
4. [9]"On Hold" Test Cases 142 and 154
* [10]Summary of Action Items
_________________________________________________________

Action Items

<scribe> ACTION: Manu to ask somebody to draft errata text,
clarifying that prefixes cannot be '_' character [recorded in
[11]http://www.w3.org/2009/11/12-rdfa-minutes.html#action10] [DONE]

[11] http://www.w3.org/2009/11/12-rdfa-minutes.html#action10

<scribe> ACTION: Mark to author URIs in @about, @rel, @rev, @typeof
and @datatype spec text [recorded in
[12]http://www.w3.org/2009/11/12-rdfa-minutes.html#action09] [DONE]

[12] http://www.w3.org/2009/11/12-rdfa-minutes.html#action09

Mark: Yes, that's done... finding link now.
<markbirbeck>
[13]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009N
ov/0081.html

[13]
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Nov/0081.html

<scribe> ACTION: Someone let Ivan know what Open Document Format
reference to use in the charter [recorded in
[14]http://www.w3.org/2009/11/19-rdfa-minutes.html#action08] [DONE]

[14] http://www.w3.org/2009/11/19-rdfa-minutes.html#action08

<scribe> ACTION: Manu to aggressively push review of test cases via
mailing list [recorded in
[15]http://www.w3.org/2009/10/29-rdfa-minutes.html#action08]
[CONTINUES]

[15] http://www.w3.org/2009/10/29-rdfa-minutes.html#action08

<scribe> ACTION: Manu to try and find other interested parties in
RDFa WG. [recorded in
[16]http://www.w3.org/2009/10/22-rdfa-minutes.html#action08]
[CONTINUES]

[16] http://www.w3.org/2009/10/22-rdfa-minutes.html#action08

RDFa WG charter status

Manu: How is the process going?

Ivan: Formally, charter is under review
... Waiting to hear back on comments.
... It is based on those reviews that the RDFa WG is formed or not
... I think things are going well
... Want to get official vote request by the end of next week... but
it's up to the reviewers to get back to us.
... The charter starts the group on Feb 1st 2010

Manu: Should we meet in Jan?

Ivan: No reason why we shouldn't meet informally.

Shane: Actually, XHTML2 continues until we close the work we're
doing.

Ivan: So, we can meet formally in January.

@vocab discussion

Manu: What are thoughts on moving forward on this?
... Do we want to ask for proposals now?

Mark: Interesting that Toby and Ivan are implementing this stuff
straight away.
... Toby implemented a way of not requiring a colon
... That's good, but also comes with downside of solidifying ideas
that we may not be the direction we want to go.
... The whole @profile issue is still there.
... Maybe we can do content negotiation?
... Maybe the thing at the end of the URI could be anything? like
have an RDFa document or JSON?
... We may want to see if we're happy with the general idea of
prefix-less CURIE
... Then I think the second step is how to give somebody a list of
how to define these tokens externally.

Ivan: So, just to clarify - next/prev/stylesheet would all be
considered "tokens"
... So, what we are trying to find is how to define those reserved
words.
... XHTML is the only one that has these reserved words, SVG
doesn't?

Manu: Not sure that's true

Steven: Yes, not clear in the SVG Tiny 1.2 spec.

Manu: We might want to just do some spec text, then?

Mark: Might be good to discuss some other points first?
... So, we got to a certain point with the discussion with Ben -
whether you regard a reserved word as a relative URI or a token
... Both will work, if there is no token defined - it's a relative
URI, if a token is defined, we use that.

<Steven> I think the fact that we have relative URIs and keywords in
the same position makes it harder to find a solution

Mark: With this recent change to allow URIs everywhere, we've got a
few more options.

Manu: I'm concerned about intermediate formats.
... What happens when you have vocab="[17]http://example.org/terms"
property="foo" and you can't resolve "[18]http://example.org/terms"
?

[17] http://example.org/terms
[18] http://example.org/terms

Mark: Well, you generate a triple with
"[19]http://example.org/terms#foo" and perhaps resolve that in the
future.
... Well, Ben mentioned that "foo" would be placed in the default
namespace... which we didn't really want.

[19] http://example.org/terms#foo

Ivan: my problem is a bit more fundamental than that.
... I'm not fully convinced that we need to go down that route...
... none of these solutions seem to be simple (for an implementer) -
still not convinced that we need to do that.
... When we go to other dialects of SVG - I don't see what the
problem we're trying to solve for those other languages are...

Mark: The problem is about trying to get Microformats-style
simplicity for markup.

Manu: Yes

Mark: It could potentially give RDFa the ability to do everything
good that Microformats does in a way that is rigorous.
... The good things about Microformats is that it's easy to
understand. Quick to get something up and going.
... The second thing that is related is that you get people like
Google that have one uber-vocabulary.
... It's the ability to just stick a @profile at the top of the
document rather than 12 namespaces, is useful for authors.

Steven: i am definitely a big fan of simplicity of authoring.
... There are good proposals for automatic namespaces by Liam et. al

Ivan: I agree with Steven on the point that @tokens become less
important when we have a mechanism for defining prefixes/tokens.
... If we have that, then I think we can forget about this @token
issue, except for the XHTML tokens, which are included.

Mark: If there is a URI mapping defined, then using it in an
attribute that can take a CURIE, even without a colon, is
sufficient.

Ivan: if we have a token/keyword without a colon, what do we do with
it.
Mark: So, let me give an example...

<markbirbeck> @xmlns:dc="[20]http://xyz"

[20] http://xyz/

<markbirbeck> dc:creator

<markbirbeck> dc:

<markbirbeck> @xmlns:creator="[21]http://xyz#creator"

[21] http://xyz/#creator

<markbirbeck> creator:

<markbirbeck> property="creator"

Mark: We can still argue that you don't need @tokens or you do - but
this is a very tiny change.

Ivan: So, I could create a ton of xmlns:xyz for all DC terms.
... This make sense only if there is a way to specify those xmlns
elsewhere.

<markbirbeck> <html

<markbirbeck> xmlns:Agent="[22]http://purl.org/dc/terms/Agent"

[22] http://purl.org/dc/terms/Agent

<markbirbeck> xmlns:Person="[23]http://xmlns.com/foaf/0.1/Person"

[23] http://xmlns.com/foaf/0.1/Person

<markbirbeck> xmlns:title="[24]http://xmlns.com/foaf/0.1/title"

[24] http://xmlns.com/foaf/0.1/title

<markbirbeck> xmlns:fn="[25]http://xmlns.com/foaf/0.1/name"

[25] http://xmlns.com/foaf/0.1/name

<markbirbeck> >

<markbirbeck> <div

<markbirbeck> about="[26]http://www.ivan-herman.net/me"

[26] http://www.ivan-herman.net/me

<markbirbeck> typeof="Person Agent"

<markbirbeck> >

<markbirbeck> <h1>

<markbirbeck> <span property="title">Dr</span>

<markbirbeck> <span property="fn">Ivan Herman</span>

<markbirbeck> </h1>

<markbirbeck> </div>

<markbirbeck> </html>

Mark: if we go for this small change, it still doesn't matter how we
get those URI mappings.

<Zakim> ShaneM, you wanted to speak for being able to define new
reserved words

Shane: I don't have a problem with this @token proposal.
... Without having an external mechanism, it's not terribly useful.
... In todays spec, we have these things called "reserved words"
... Those only work for @rel/@rev
... That's fine.
... So, we're extending these to all CURIE-aware attributes?

Mark: Not necessarily - we have this new mechanism for @property for
resolving reserved words/CURIEs.

Shane: So, putting on my DAISY hat, they want to be able to define
reserved words.
... We still need to be able to have a way to change the default
collection of reserved words.

Manu: We still don't have a solution for defining extended reserved
words.

<ShaneM> aside: what if I have multiple profile references and there
are collisions after taking the union of the prefix mappings? Last
takes precedence?

Ivan: Let's say we have a @profile - we could pull @tokens in from
an external document.

Mark: yes, agree with Ivan
... With this minor change, it helps us solve the other
Microformats-like-markup problem.

<ShaneM> I want a "prefix import mechanism" not a "namespace import
mechanism"

<Zakim> ShaneM, you wanted to say that I dont want to rely on these
external namespace proposals. we are too tied to namespaces already!

"On Hold" Test Cases 142 and 154

<scribe> ACTION: Mark to generate spec text for @token and @prefix
[recorded in
[27]http://www.w3.org/2009/12/03-rdfa-minutes.html#action06]

<ShaneM> I suddenly grok why @prefix is a bad name

<scribe> ACTION: Mark to generate spec text for pulling in external
vocabulary documents [recorded in
[28]http://www.w3.org/2009/12/03-rdfa-minutes.html#action07]

<scribe> ACTION: Manu to generate spec text for pulling in external
vocabulary documents. [recorded in
[29]http://www.w3.org/2009/12/03-rdfa-minutes.html#action08]

<ShaneM> @cmap="token URI"

<ShaneM> where cmap == curie mapping

[30]http://rdfa.digitalbazaar.com/test-suite/

[30] http://rdfa.digitalbazaar.com/test-suite/

<p xmlns:xml="[31]http://www.w3.org/XML/1998/namespace"
property="xml:test">Test</p>

[31] http://www.w3.org/XML/1998/namespace

Manu: Thoughts?

Shane: keep it on hold.

Ivan: Maybe we could disallow it in the spec?

Mark: It's an edge case that we don't refer to.
Manu: So, we'll keep it on hold and I'll contact LibXML developers
to fix the library, once it is fixed, we will approve the test case.

<scribe> ACTION: Manu to get in touch with LibXML developers about
TC 142. [recorded in
[32]http://www.w3.org/2009/12/03-rdfa-minutes.html#action09]

<span xmlns:test="[33]http://example.org/error/"
property="testŀ:test">Test</span>

[33] http://example.org/error/

Ivan: So I can only have ASCII characters there?

Shane: Yes.

Manu: Ok, so this is an invalid XHTML test, but we will be
revisiting this issue for HTML4 and HTML5.

Summary of Action Items

[NEW] ACTION: Manu to generate spec text for pulling in external
vocabulary documents. [recorded in
[34]http://www.w3.org/2009/12/03-rdfa-minutes.html#action08]
[NEW] ACTION: Manu to get in touch with LibXML developers about TC
142. [recorded in
[35]http://www.w3.org/2009/12/03-rdfa-minutes.html#action09]
[NEW] ACTION: Mark to generate spec text for @token and @prefix
[recorded in
[36]http://www.w3.org/2009/12/03-rdfa-minutes.html#action06]
[NEW] ACTION: Mark to generate spec text for pulling in external
vocabulary documents [recorded in
[37]http://www.w3.org/2009/12/03-rdfa-minutes.html#action07]

[PENDING] ACTION: Manu to aggressively push review of test cases via
mailing list [recorded in
[38]http://www.w3.org/2009/10/29-rdfa-minutes.html#action08]
[PENDING] ACTION: Manu to try and find other interested parties in
RDFa WG. [recorded in
[39]http://www.w3.org/2009/10/22-rdfa-minutes.html#action08]

[38] http://www.w3.org/2009/10/29-rdfa-minutes.html#action08
[39] http://www.w3.org/2009/10/22-rdfa-minutes.html#action08

[DONE] ACTION: Manu to ask somebody to draft errata text, clarifying
that prefixes cannot be '_' character [recorded in
[40]http://www.w3.org/2009/11/12-rdfa-minutes.html#action10]
[DONE] ACTION: Mark to author URIs in @about, @rel, @rev, @typeof
and @datatype spec text [recorded in
[41]http://www.w3.org/2009/11/12-rdfa-minutes.html#action09]
[DONE] ACTION: Someone let Ivan know what Open Document Format
reference to use in the charter [recorded in
[42]http://www.w3.org/2009/11/19-rdfa-minutes.html#action08]

[40] http://www.w3.org/2009/11/12-rdfa-minutes.html#action10
[41] http://www.w3.org/2009/11/12-rdfa-minutes.html#action09
[42] http://www.w3.org/2009/11/19-rdfa-minutes.html#action08

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [43]scribe.perl version 1.135
([44]CVS log)
$Date: 2009/12/03 18:58:57 $
_________________________________________________________

[43] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[44] http://dev.w3.org/cvsweb/2002/scribe/

--

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

Re: Call for Review of XHTML Test Cases 172, 173, and 174

2009-12-03T08:08:28Z

Manu Sporny wrote:

> This is a call for review for Test Cases 172, 173, and 174. Everybody is
> encouraged to review these test cases. Reviews are due by next Thursday,
> 1600 UTC.
>
> The test cases can be found at the following URL:
>
> http://rdfa.digitalbazaar.com/test-suite/
>
> For "Test Suite", select: "XHTML+RDFa 1.0"
> For "Unit Test Status", select: "Unreviewed"
>
> Here is a template to follow when responding:
>
> TC172: approved/rejected/approved with modifications/needs discussion
> TC173: approved/rejected/approved with modifications/needs discussion
> TC174: approved/rejected/approved with modifications/needs discussion
>

TC172: approved
TC173: approved
TC174: approved - but this seems really really goofy to me

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

Telecon Agenda - 3 December 2009, 1600 UTC

2009-12-02T12:40:34Z

Hi all,

We have a Telecon tomorrow. Let's get a status update for RDFa WG
charter stuff, continue the @vocab discussion and briefly cover "On
Hold" Test cases.

-- manu

==========
Thursday, December 3rd 2009
1500 UTC, W3C Zakim bridge
tel:+1.617.761.6200 conference code RDFA
irc://irc.w3.org:6665/#rdfa
Duration: 60 minutes
Scribe: Zakim, pick a victim
==========

Agenda

1) Action Items:
http://www.w3.org/2009/11/19-rdfa-minutes.html#ActionSummary

2) WG charter status update

3) @vocab discussion
* Perhaps we want to just make a call for proposals at this point?
* Mark could do a proposal, I can volunteer to create a proposal?

4) "On Hold" Test Cases 142 and 154

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2 Launched - The Legal P2P Music Network
http://blog.digitalbazaar.com/2009/11/30/bitmunk-3-2-launched/

Re: Non-XHTML host languages for RDFa

2009-12-02T01:20:46Z

On Tue, 2009-12-01 at 23:57 +0100, Christoph LANGE wrote:
> 2009-12-01 18:17 Toby Inkster <tai@...>:
> > 1. Allows lists of keywords to be configured on a per-attribute basis
> > for @rel, @rev, @property, @datatype, @typeof, @about, @resource and
> > @graph.
>
> aha, that sounds like an interesting approach, to enable that per
> attribute. Not sure whether it should really be different for, e.g.
> @rel and @rev, and whether one would want keywords on @about and
> @resource, but, well, why not? Let's see how people use it.

I imagine that people would define @rel and @rev the same. As it's a
structure that uses pointers (a hashref in Perl), it's pretty easy to
set @rev's keywords list to be a pointer to @rel's. But they can be used
separately if need be.

> (What is @graph BTW?)

RDF::RDFa::Parser has experimental support for quad-based RDFa parsing
as per <http://buzzword.org.uk/2009/rdfa4/spec>. (Support is disabled by
default.)

> > 4. Supports colon-less CURIE prefixes (e.g.
> > xmlns:foafname="http://xmlns.com/foaf/0.1/name"
> property="foafname").
>
> I have always thought that a name_space_ is something that contains a
> lot of localnames. So this is indeed a creative (ab)use of
> "namespaces" that only contain a single entity. I wouldn't say it is
> illegal, though, it's definitely an interesting and elegant hack.

It's legal in RDFa to do this:

xmlns:foafname="http://xmlns.com/foaf/0.1/name" property="foafname:"

Enabling the colon-less option just allows that last colon to be
omitted. This idea comes from Mark Birbeck's article here:
<http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web>

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

Re: Non-XHTML host languages for RDFa

2009-12-01T14:57:51Z

Hi Toby,

2009-12-01 18:17 Toby Inkster <tai@...>:
> 1. Allows lists of keywords to be configured on a per-attribute basis
> for @rel, @rev, @property, @datatype, @typeof, @about, @resource and
> @graph.

aha, that sounds like an interesting approach, to enable that per attribute.
Not sure whether it should really be different for, e.g. @rel and @rev, and
whether one would want keywords on @about and @resource, but, well, why not?
Let's see how people use it. (What is @graph BTW?)

> 4. Supports colon-less CURIE prefixes (e.g.
> xmlns:foafname="http://xmlns.com/foaf/0.1/name" property="foafname").

I have always thought that a name_space_ is something that contains a lot of
localnames. So this is indeed a creative (ab)use of "namespaces" that only
contain a single entity. I wouldn't say it is illegal, though, it's
definitely an interesting and elegant hack.

Cheers,

Christoph

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

signature.asc (205 bytes) Download Attachment

Re: Non-XHTML host languages for RDFa

2009-12-01T09:17:07Z

For flexible integration with non-XHTML host languages, the next version
of RDF::RDFa::Parser has the following optional features:

1. Allows lists of keywords to be configured on a per-attribute basis
for @rel, @rev, @property, @datatype, @typeof, @about, @resource and
@graph.

2. Allows CURIE prefixes to be treated case-insensitively (good for
HTML).

3. Allows the empty CURIE prefix to be changed.

4. Supports colon-less CURIE prefixes (e.g.
xmlns:foafname="http://xmlns.com/foaf/0.1/name" property="foafname").

RDF::RDFa::Parser is not an end-user tool, but a library for Perl. These
options are switched on by the programmer using the library, not by the
document itself.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

Re: NEW RDFa Test Suite (XHTML1.1, HTML4 and HTML5)

2009-12-01T07:13:52Z

On Mon, 2009-11-30 at 23:03 +0000, Toby Inkster wrote:
> Right now I'm passing all XHTML1 tests, and all but three of the HTML
> tests (failing the same three in both HTML4 and HTML5).

Last night I spent ages puzzling over why I was failing test 0121 in
HTML4 and HTML5, but not XHTML1, and today it's come to me out of
nowhere.

<p about="http://example.org/">
<span about="[]" property="dc:title">Test Case 0121</span>
checks to make sure RDFa processors resolve the empty CURIE correctly.
<p resource="[]">
<span property="dc:contributor">Shane McCarron</span>
contributed to this test.
</p>
</p>

In HTML, paragraphs cannot be nested. (In XHTML1 this is invalid too,
but well-formed.) Thus, in parsing, the opening of the second paragraph
automatically closes the first paragraph. Thus the above parses as if it
were:

<p about="http://example.org/">
<span about="[]" property="dc:title">Test Case 0121</span>
checks to make sure RDFa processors resolve the empty CURIE correctly.
</p>
<p resource="[]">
<span property="dc:contributor">Shane McCarron</span>
contributed to this test.
</p>

So the subject of the second triple is the implicit about="" on the
<body> element. So, as far as HTML parsing is concerned, my parser is
right and the test case's SPARQL result is wrong.

Suggestion: replace the second <p> element with <b> or something.

My suggestion to drop test case 0113 from the HTML test suites still
stands too.

As I believe these two test cases in the HTML test suites are erroneous,
I won't be changing my parser to "pass" them. Other than that,
RDF::RDFa::Parser is now passing all the HTML4, HTML5 and XHTML1 tests.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

Re: Non-XHTML host languages for RDFa

2009-12-01T07:01:54Z

On Tue, 01 Dec 2009 15:43:29 +0100, Shane McCarron <shane@...>
wrote:

>
>
> Steven Pemberton wrote:
>>
>> That's the current state of play if you have some SVG in the middle of
>> some XHTML. SVG defines a different set of keywords to XHTML.
>
> Err... what? Are you suggesting that RDFa embedded in SVG *today* is
> using different reserved words than those defined by the default
> vocabulary? If so, that would imply that no RDFa processor I know of
> would raise triples out of that correctly.

It's what the SVG spec says, that's all.

Steven

Re: Non-XHTML host languages for RDFa

2009-12-01T06:48:09Z

Shane McCarron wrote:

As far as I can see, SVG does _not_ define any reserved words. I
honestly do not know what would be the rule if SVG was embedded in HTML,
though. I am not sure we have a decision on that.

Ivan

--

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

Re: Non-XHTML host languages for RDFa

2009-12-01T06:43:29Z

Steven Pemberton wrote:
>
> That's the current state of play if you have some SVG in the middle of
> some XHTML. SVG defines a different set of keywords to XHTML.

Err... what? Are you suggesting that RDFa embedded in SVG *today* is
using different reserved words than those defined by the default
vocabulary? If so, that would imply that no RDFa processor I know of
would raise triples out of that correctly.

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

Re: Non-XHTML host languages for RDFa

2009-12-01T05:54:09Z

On Mon, 30 Nov 2009 17:39:11 +0100, Shane McCarron <shane@...>
wrote:

>
>
> 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?

That's the current state of play if you have some SVG in the middle of
some XHTML. SVG defines a different set of keywords to XHTML.

Steven

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

2009-12-01T05:50:31Z

On Tue, 01 Dec 2009 14:47:24 +0100, Mark Birbeck
<mark.birbeck@...> wrote:

> Hi Steven,
>
> On Tue, Dec 1, 2009 at 1:03 PM, Steven Pemberton
> <Steven.Pemberton@...> wrote:
>> Actually I have long wanted an easy way of saying "about the current
>> element".
>>
>> Off the top of my head, something like:
>>
>> <p about="[.]">
>>
>> or
>> <p about="[_:.]"
>
> Ah...but that's why I was keen to clarify the behaviour of an empty
> @typeof:
>
> <div typeof="">
> ...
> </div>
>
> This give the current element a bnode, ready for use by further
> statements.

Yes, but removing the ability to use typeof.

Steven

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

2009-12-01T05:47:24Z

Hi Steven,

On Tue, Dec 1, 2009 at 1:03 PM, Steven Pemberton
<Steven.Pemberton@...> wrote:
> Actually I have long wanted an easy way of saying "about the current
> element".
>
> Off the top of my head, something like:
>
> <p about="[.]">
>
> or
> <p about="[_:.]"

Ah...but that's why I was keen to clarify the behaviour of an empty @typeof:

<div typeof="">
...
</div>

This give the current element a bnode, ready for use by further statements.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

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

2009-12-01T05:03:06Z

Actually I have long wanted an easy way of saying "about the current
element".

Off the top of my head, something like:

<p about="[.]">

or
<p about="[_:.]"

Steven

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

2009-12-01T03:02:32Z

Hi Mark,

2009-12-01 11:31 Mark Birbeck <mark.birbeck@...>:

> But Christoph seems to be saying that his language needs to make lots
> of statements about the document itself, resulting in a common pattern
> of:
>
> <x id="y" about="#y">
> ...
> </x>
>
> I don't have any immediate suggestions about how to work around this,
> although I'm sure we could come up with something. But I would caution
> against using @id in a language, to automatically generate a subject,
> since I think it will cause problems for that language in the longer
> term.

Indeed automatic generation of subjects may be tricky, and that's also why I
didn't pursue this any further. The actual OMDoc situation is that certain
_elements_ denote formal concepts just by their existence. E.g.
<definition><link rel="dc:creator" resource="x:me"/>...</definition> denotes a
definition that has some creator. While it is strongly
recommended that such elements carry an @xml:id so that we can refer to them
by URI, it is not strictly required. Now think of the above XML as "there
exists a definition created by x:me", and think of the correspondence of
bnodes to existentially quantified variables. Compatibility to other RDFa
processors aside, if we had this automatic subject generation, the way of
doing it "right" would be: If an @xml:id "i" exists, make #i the subject;
otherwise generate a bnode _:someid and make _:someid the subject. Not sure
if that is nice, though, it is certainly a bit too far away from RDFa
compatibility.

Cheers,

Christoph

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

signature.asc (205 bytes) Download Attachment

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

2009-12-01T02:59:34Z

Hi Christoph,

Christoph LANGE wrote:

>
> BTW, another related question: When generating XHTML+RDFa from a formal
> representation that is already RDF-compatible in itself (e.g. RDF/XML, e.g.
> OWL, e.g. OMDoc, …), I suppose that both the original representation and the
> XHTML+RDFa should use the same URIs for the same things. Suppose the original
> document, e.g. having the URI doc.omdoc, contains a triple with subject
> #resource, and suppose we generate doc.xhtml with RDFa from it. A naïve
> translation might create something like <div about="#resource">, i.e. talk
> about a resource doc.xhtml#resource. But I guess it should rather be <div
> about="doc.omdoc#resource">, as the formal concept will stay the same,
> regardless of its presentation. Are there similar experiences from, e.g.,
> generating XHTML+RDFa from OWL?
>

I do not know about generating from OWL, but I fully agree with the
rest. There should be one URI.

In my own authoring I use <base> extensively, as well as protected
CURIE-s for @about (and that is also why I am happy that I will be able
to use, possibly, curies directly...). I avoid thereby to generate URI-s
with the filename as a base URI which is, most of the time in my
experience, is the _wrong_ one...

Ivan

> Cheers,
>
> 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

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

2009-12-01T02:46:13Z

Dear Toby, Ivan, all,

thanks for your comments! Indeed I agree with Ivan that it makes sense to
stick to @about, as normal RDFa processors currently support it that way, and
one of our main points in using RDFa at all was the wide support for it.

While we will also publish XHTML+RDFa documents _generated_ from our OMDoc
documents on the web (will be online in a few days from now), which contain
even more RDFa extracted from our markup than those metadata for which we use
RDFa in the _input_ syntax (i.e. OMDoc), the OMDoc sources will also be
online. Then, we'd risk spreading inconsistencies, if crawlers parsed both
the RDFa in OMDoc, not knowing about implicit @about's, and the generated
XHTML+RDFa with spec-conforming @about's. Therefore, we are indeed thinking
about having editors and other tools support the user in creating those --
seemingly redundant -- @about's.

2009-12-01 10:53 Ivan Herman <ivan@...>:
> At the moment, the rdfa distiller has a flag on whether it is XML or
> HTML, essentially taking care of things like xml:base and possibly
> existing RDF/XML portions. I would hate to have to have all kinds of
> different options for different XML applications...

My current favorite position on that is: Use @about for now, but hope for
some declarative mechanism that allows us to specify custom parsing rules for
RDFa in different host languages (for which e.g. @profile has been suggested
in the other thread).

BTW, another related question: When generating XHTML+RDFa from a formal
representation that is already RDF-compatible in itself (e.g. RDF/XML, e.g.
OWL, e.g. OMDoc, …), I suppose that both the original representation and the
XHTML+RDFa should use the same URIs for the same things. Suppose the original
document, e.g. having the URI doc.omdoc, contains a triple with subject
#resource, and suppose we generate doc.xhtml with RDFa from it. A naïve
translation might create something like <div about="#resource">, i.e. talk
about a resource doc.xhtml#resource. But I guess it should rather be <div
about="doc.omdoc#resource">, as the formal concept will stay the same,
regardless of its presentation. Are there similar experiences from, e.g.,
generating XHTML+RDFa from OWL?

Cheers,

Christoph

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

signature.asc (205 bytes) Download Attachment

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

2009-12-01T02:31:53Z

Hi Ivan,

There has been discussion about @id being 'special' over the years,
but it's been quite piecemeal. So it's probably not your memory that
means you don't recall this. :)

However, when the proposition has come up, I believe a few
'principles' have emerged about why we should avoid giving @id special
status, and it might help the discussion if I explain some of them.

The main 'principle' that has been repeated a few times over the
years, is that it's important to be able to talk separately about the
data in the document, and the document itself.

The 'data in the document' might be an address or vCard.

The 'document itself' might be not only the document, but a footer,
sidebar, etc.

That's no different to the usual 'information resource' issue that
crops up a lot in RDF, where we want to be able to talk about the
web-page itself (when was it published, who by, etc.), and the the
information it represents (the item for sale, the person, etc.).

Note that RDF doesn't require there to be anything at the end of a
URI, which means that we don't actually need to use the pattern that
many people are using in their FOAF files:

<div id="me" about="#me">
...
</div>

Instead, the following is sufficient:

<div about="#me">
...
</div>

Anyway, if we agree that there are important uses for being able to
talk about the document itself, distinct from its content, then we can
also see that making @id automatically provide a subject would
completely mess up the normal RDFa parsing -- one moment you are
talking about a person's FOAF file, and then suddenly your statements
are about the elements in the document.

(Note that RDFa provides an RDF 'interpretation' of existing semantic
content, such as @rel and @href. But with @id, it's difficult to see
the semantic content that is added, that could then be 'interpreted'
as RDF.)

But Christoph seems to be saying that his language needs to make lots
of statements about the document itself, resulting in a common pattern
of:

<x id="y" about="#y">
...
</x>

I don't have any immediate suggestions about how to work around this,
although I'm sure we could come up with something. But I would caution
against using @id in a language, to automatically generate a subject,
since I think it will cause problems for that language in the longer
term.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

On Tue, Dec 1, 2009 at 8:35 AM, Ivan Herman <ivan@...> wrote:

> 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
>

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

2009-12-01T01:53:02Z

Toby Inkster wrote:

> 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...".
>

Hm. I would try to avoid that...

At the moment, the rdfa distiller has a flag on whether it is XML or
HTML, essentially taking care of things like xml:base and possibly
existing RDF/XML portions. I would hate to have to have all kinds of
different options for different XML applications...

> 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.
>

yes, that is a solution. I think having one generic RDFa feature set is
what we should try to achieve...

Ivan

--

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

Re: Non-XHTML host languages for RDFa

2009-12-01T01:48:04Z

Hi Toby,

On Tue, Dec 1, 2009 at 9:16 AM, Toby Inkster <tai@...> wrote:

> 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.

Yes -- I know.

> 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.

As with anything, you would use profiles from people and places you trust.

Any unease someone has about using a profile from a Google server (for
example), would apply equally to using Google Maps in their pages. In
fact, the whole system of Google providing a CDN for JS libraries like
jQuery and YUI, is equally suspect -- if you trust their CDN, trust
their profiles...otherwise don't use either. :)

But anyway, the main point I'm getting at is that we don't want to
limit the technological choice for creating token lists.

Many people have mentioned that it would be nice to use RDFa to
describe the tokens, and whilst there is obviously an attractive
symmetry about doing that, I'm flagging up that if that was the /only/
solution on offer, it would be difficult for browsers to obtain the
data, without going via some kind of proxy.

On the other hand, if a number of methods are supported, we have more
flexibility.

This would imply coming up with a way of defining tokens that is
syntax-independent -- perhaps using RDF.

In short, I'm suggesting that we stick with discussing the general
solution, before alighting on a particular delivery mechanism.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

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

2009-12-01T01:21:48Z

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:mail@...>
<http://tobyinkster.co.uk>

Re: Non-XHTML host languages for RDFa

2009-12-01T01:16:11Z

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:mail@...>
<http://tobyinkster.co.uk>

Re: Non-XHTML host languages for RDFa

2009-12-01T00:48:06Z

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

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

2009-12-01T00:35:39Z

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

Re: Call for Review of XHTML Test Cases 172, 173, and 174

2009-11-30T23:36:52Z

These all pass in my (unreleased) development version.

By the way, I'm moving active development of the Ruby RDFa parser to Reddy, My clone at http://github.com/gkellogg/reddy contains the RdfaParser, a new conforming RDF/XML parser and an N3 parser, along with improved graph semantics. I'm still working on some improvements to the Graph model with support for multiple stores, but hope to have something released in the next couple of weeks.

Gregg

On Nov 29, 2009, at 2:22 PM, Manu Sporny wrote:

This is a call for review for Test Cases 172, 173, and 174. Everybody is
encouraged to review these test cases. Reviews are due by next Thursday,
1600 UTC.

The test cases can be found at the following URL:

http://rdfa.digitalbazaar.com/test-suite/

For "Test Suite", select: "XHTML+RDFa 1.0"
For "Unit Test Status", select: "Unreviewed"

Here is a template to follow when responding:

TC172: approved/rejected/approved with modifications/needs discussion
TC173: approved/rejected/approved with modifications/needs discussion
TC174: approved/rejected/approved with modifications/needs discussion

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/

Re: Non-XHTML host languages for RDFa

2009-11-30T17:17:55Z

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 mark.birbeck@...:

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: shane@...

Re: Non-XHTML host languages for RDFa

2009-11-30T16:28:46Z

Hi Mark,

thanks for pointing out the possibilities!

2009-12-01 01:05 Mark Birbeck <mark.birbeck@...>:

> > 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

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

2009-11-30T16:09:48Z

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

Re: Non-XHTML host languages for RDFa

2009-11-30T16:05:38Z

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

mark.birbeck@...

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)

Re: Non-XHTML host languages for RDFa

2009-11-30T15:43:51Z

2009-11-30 14:51 Mark Birbeck <mark.birbeck@...>:

> > 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

Re: NEW RDFa Test Suite (XHTML1.1, HTML4 and HTML5)

2009-11-30T15:03:08Z

On Sun, 2009-09-20 at 19:00 -0400, Manu Sporny wrote:
> I spent some time this weekend re-writing the RDFa test harness so
> that it would let us test XHTML1.1, HTML4 and HTML5 using a unified
> set of tests.

I've been testing RDF::RDFa::Parser against this test suite. (It was
already passing the ones on the W3C website.) I have a query:

HTML4 and HTML5 include test case 0113, which includes the following:

<body>
<span about="#a" property="dc:title"></span>
<span about="#b" property="dc:title" />
</body>

And claims that the literals generated from each <span> should be
identical. However, in HTML 4, "/>" does not represent a self-closing
tag. Strictly speaking, if you want to follow the formal SGML SHORTTAG
rules, I believe it's equivalent to this:

<body>
<span about="#a" property="dc:title"></span>
<span about="#b" property="dc:title" >>
</body>

Though that's invalid because the second <span> element is never closed.
So, strictly following HTML4, the best literal a parser could come up
with would be ">\n ". Using HTML5 parsing, it would be "\n ". Either
way, I don't think this test should be included in the HTML test cases.
If it is to be included, "" should not be the literal expected from the
second <span>.

Right now I'm passing all XHTML1 tests, and all but three of the HTML
tests (failing the same three in both HTML4 and HTML5).

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

Re: Proposal for 'URIs everywhere'

2009-11-30T08:45:23Z

Steven Pemberton wrote:
>
> No, please not. As far as I am concerned about="next" must always mean
> the same as about="./next". It must always be a URI.
>
+1

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

Re: Non-XHTML host languages for RDFa

2009-11-30T08:39:11Z

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: shane@...

Re: Proposal for 'URIs everywhere'

2009-11-30T07:32:11Z

>> Ie: what about removing that asymmetry altogether, and say that
>> predefined keywords are also valid for @about and @resource? It would
>> make the URI management simpler and cleaner and I do not really see a
>> major drawback...
>
> No, please not. As far as I am concerned about="next" must always mean
> the same as about="./next". It must always be a URI.
>
> Steven
>

Differences of sensibilities, obviously... the asymmetry between @rel
and @about bothers me more than a coincidence of one of the keywords
with a possible relative URI-s

Ivan

--

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

Re: Basic semantic sitemap in RDFa for Drupal

2009-11-30T06:51:06Z

Stephane Corlosquet wrote:

> Hi Steven,
>
> Thanks for your feedback!
>
> On Mon, Nov 30, 2009 at 8:58 AM, Steven Pemberton
> <Steven.Pemberton@...>wrote:
>
>> Looks good to me.
>>
>> There's something slightly odd with classifying people's names as being in
>> the same language as the document:
>>
>> <http://drupalrdf.openspring.net/user/20> a sioc:User ;
>> foaf:name "lucerukimam"@en .
>>

shouldn't this be:

<http://drupalrdf.openspring.net/user/20> a sioc:User ;
sioc:account_of <http://drupalrdf.openspring.net/user/20#person> .

<http://drupalrdf.openspring.net/user/20#person> a foaf:Person ;
foaf:name "lucerukimam"@en ;

since foaf:name relates to a foaf:person and sioc:User is simply an
account of said Person