Nabble - w3.org - rdf

Re: Proposal for 'URIs everywhere'

2009-11-27T09:18:05Z

I redid the relevant part of my distiller, too, and it is much nicer and
simpler. It is one single method that has some internal branches, but
can still handle @rel/@rev/@about/@resource/@typeof in one place. An
this is nice. What it does with 'value':

1. Get the possible safe curie signs out of the way at the start, ie, if
the value is of the form '[...]' then remove the [ and ] signs. Ie, the
safe curie is there for backward compatibility only. (And yes, that
means that I do allow unsafe curies for @about and @resource)

2. Get the possible blank node management out of the way, ie return the
right blank node for things like '_:a'. Note that if this is called for
a @rel/@property/@ref, then return None (with possible error message)
because you cannot have a blank node for a predicate

3. If it is called on @rel/@rev and the value is a keyword then return
the corresponding URI

4. Try to match the value against a CURIE definition (ie, see if it is
of the form a:b and 'a' is defined as a namespace, oops, local name). If
yes, return the corresponding URI

5. If we get here, this is a real URI (absolute or relative), and fall
back to the usual URI management to get the final URI (there are python
tools to do that with all the quirks of relative uris and the like).

I think this is in line with what Mark describes. I have written it down
here to see if it is what Mark had in mind (until we have relevant test
cases...)

I plan to test a bit more and put up a test version of the distiller
service on line with an extra "1.1" flag to trigger this behaviour.
Hopefully on the week end or early next week.

Ivan

Toby Inkster wrote:

> On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
>> Anyway, below you'll find a series of minor changes that I feel would
>> need to be made to various parts of the syntax document, in order to
>> support URIs and CURIEs in all RDFa-related attributes (except @src
>> and @href).
>
> The following describes the behaviour of the unreleased
> RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
> 0.20.)
>
> If the parser is instantiated with the option "full_uris" set to true,
> then, it uses the following behaviour for these attributes:
>
> @about/@resource: Safe CURIE, falling back to URIs.
> @src/@href: URIs only.
> @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
> @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.
>
> I think this is more or less the same as your proposal, except that
> unsafe CURIEs are disallowed in @about/@resource.
>
> By default, i.e. when "full_uris" is not true, it uses:
>
> @about/@resource: Safe CURIE, falling back to URIs.
> @src/@href: URIs only.
> @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
> @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.
>
> And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa
> test suite. (Yay!)
>

--

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

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Proposal for 'URIs everywhere'

2009-11-26T07:25:23Z

On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote:
> Anyway, below you'll find a series of minor changes that I feel would
> need to be made to various parts of the syntax document, in order to
> support URIs and CURIEs in all RDFa-related attributes (except @src
> and @href).

The following describes the behaviour of the unreleased
RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is
0.20.)

If the parser is instantiated with the option "full_uris" set to true,
then, it uses the following behaviour for these attributes:

@about/@resource: Safe CURIE, falling back to URIs.
@src/@href: URIs only.
@rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs.
@property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs.

I think this is more or less the same as your proposal, except that
unsafe CURIEs are disallowed in @about/@resource.

By default, i.e. when "full_uris" is not true, it uses:

@about/@resource: Safe CURIE, falling back to URIs.
@src/@href: URIs only.
@rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs.
@property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs.

And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa
test suite. (Yay!)

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

From forum: w3.org - public-rdf-in-xhtml-tf

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

2009-11-26T07:25:19Z

Hi Toby,

thanks for your helpful comments!

2009-11-26 12:25 Toby Inkster <tai@...>:
> 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

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Proposal for 'URIs everywhere'

2009-11-26T06:07:35Z

Julian Reschke wrote:

> Mark Birbeck wrote:
>> Hi Julian,
>>
>> Thanks for this.
>>
>> The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
>> everywhere.
>
> Ah, I missed the "...orSafeCURIE".
>
>> :)
>>
>> It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
>> I figured that using the name 'URIorCURIE' rather than
>> 'URIorCURIEorSafeCURIE', to represent this in the prose, would be
>> acceptable.
>>
>> In other words, the functionality is definitely as you describe --
>> i.e., it is backwards-compatible -- it's just that the short name I've
>> used collapses the two types of CURIE into one, more general notion,
>> of a CURIE.
>>
>> But if there's a feeling that this might confuse people, and that we
>> should use the longer term, then I don't have a problem with that
>> either.
>> ...
>
> I was confused, so my assumption would be that others will be confused
> as well.
> ...

Having said that... URIs and CURIEs use the same lexical space. On the
other hand, Safe-CURIEs have been designed to they never conflict with URIs.

If you are going to allow all three notations in the same place, you may
want to give advice which to use. I *think* the best advice would be to
use either URIs or Safe-CURIEs, and to avoid CURIEs.

Best regards, Julian

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Proposal for 'URIs everywhere'

2009-11-26T06:05:28Z

Mark Birbeck wrote:
> Hi Julian,
>
> Thanks for this.
>
> The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
> everywhere.

Ah, I missed the "...orSafeCURIE".

> :)
>
> It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
> I figured that using the name 'URIorCURIE' rather than
> 'URIorCURIEorSafeCURIE', to represent this in the prose, would be
> acceptable.
>
> In other words, the functionality is definitely as you describe --
> i.e., it is backwards-compatible -- it's just that the short name I've
> used collapses the two types of CURIE into one, more general notion,
> of a CURIE.
>
> But if there's a feeling that this might confuse people, and that we
> should use the longer term, then I don't have a problem with that
> either.
> ...

I was confused, so my assumption would be that others will be confused
as well.

Best regards, Julian

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Proposal for 'URIs everywhere'

2009-11-26T05:46:52Z

Hi Julian,

Thanks for this.

The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
everywhere.

:)

It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
I figured that using the name 'URIorCURIE' rather than
'URIorCURIEorSafeCURIE', to represent this in the prose, would be
acceptable.

In other words, the functionality is definitely as you describe --
i.e., it is backwards-compatible -- it's just that the short name I've
used collapses the two types of CURIE into one, more general notion,
of a CURIE.

But if there's a feeling that this might confuse people, and that we
should use the longer term, then I don't have a problem with that
either.

Regards,

Mark

On Thu, Nov 26, 2009 at 12:30 PM, Julian Reschke <julian.reschke@...> wrote:

> Hi,
>
> here's a high-level comment without looking at the details.
>
> I appreciate the attempt to make progress. As far as I can tell, the change
> being proposed actually will not be backwards-compatible in all cases (for
> instance, when changing from URIorSafeCURIE to URIorCURIE). In which case
> you really should consider making a change that at least avoids confusion
> and potential ambiguity, by making everything URIorSafeCURIE. That would
> also align (as far as I recall) with the TAG advice not to use CURIEs where
> they might be confused with URIs.
>
> Best regards, Julian
>
>
> Mark Birbeck wrote:
>>
>> Hello all,
>>
>> I'd hoped to get the following proposal to the group at the beginning
>> of the week, but it wasn't possible.
>>
>> Anyway, below you'll find a series of minor changes that I feel would
>> need to be made to various parts of the syntax document, in order to
>> support URIs and CURIEs in all RDFa-related attributes (except @src
>> and @href).
>>
>> To recap, whilst most of our attributes support URIs and CURIEs
>> already, @property, @rel and @rev only supported URIs. This means that
>> authors must declare prefix mappings for all predicates, even though
>> they are not required to use prefix mappings for subjects or objects.
>> We've agreed to try to address this, and I had an action item to come
>> up with some proposed text.
>>
>>
>> APPROACH
>>
>> The first step in sorting this out, is to remove the separation where
>> in some places we allow a CURIE, and in others we allow a
>> URIorSafeCURIE.
>>
>> Both situations will now use the same type, which I've called
>> 'URIorCURIE'. (This type did used to exist in previous drafts, but I
>> think that's ok. Of course, if anyone can spot a reason why we should
>> use a different name, then please mention it.)
>>
>> After making the data type consistent throughout, we then need to
>> clarify the processing rules.
>>
>> And finally, we need to add one or more examples of using a full URI
>> for a predicate.
>>
>>
>> DATATYPE
>>
>> The datatype changes affect section 2.1, as follows:
>>
>> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
>> with 'URIorCURIE'.
>> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.
>>
>> Also, in section 5.4.4, the bullet-points listing the attributes
>> should change to this:
>>
>> * @about, @datatype, @property, @resource and @typeof support either a
>> URI or
>> a CURIE.
>> * @href and @src support only a URI.
>> * @rel and @rev support XHTML link types, URIs and CURIEs.
>>
>>
>> PROCESSING
>>
>> In section 5.4.2, after the three steps, but before the note, we should
>> add:
>>
>> Note that this algorithm assumes that its input is a CURIE, but in
>> practice it
>> won't be possible to definitively establish this until step 2; if
>> there is no in-scope
>> mapping that matches the prefix, then the algorithm should terminate, and
>> the
>> input regarded as a URI.
>>
>> In section 5.4.3, the first point should be removed, and in the second
>> point, the sentence:
>>
>> In this case any value that is not surrounded by square brackets, as
>> defined
>> by 'safe_curie' in the section CURIE Syntax Definition, will be
>> processed as if
>> it was a URI.
>>
>> should be changed to:
>>
>> In this case any value that is not a CURIE, as outlined in section 5.4.2,
>> will
>> be processed as a URI.
>>
>> Note that I've left the prose about square brackets intact, because
>> there are probably use-cases where people want to say 'safe CURIE or
>> nothing'. (I.e., don't fall back to a URI if there is no prefix
>> mapping.)
>>
>> In the sentence after the two (now one) sentences, we should change this:
>>
>> An example of an attribute that can contain CURIE and non-CURIE values is
>> @about. As described, any CURIEs expressed in the attribute must follow
>> the
>> format of a [safe CURIE]. So to express a URI directly, an author
>> might do this:
>>
>> to this:
>>
>> An example of an attribute that can contain a URIorCURIE is @about. To
>> express a URI directly, an author might do this:
>>
>> After the example, the next sentence/example combination can be
>> duplicated, to give us an extra example, like this:
>>
>> whilst to express a CURIE they could do this:
>>
>> <div about="dbr:Albert_Einstein">
>> ...
>> </div>
>>
>> The author could also use a safe CURIE, as follows:
>>
>> <div about="[dbr:Albert_Einstein]">
>> ...
>> </div>
>>
>> In the next example, we just need to clarify that we're now only
>> referring to safe CURIEs; this:
>>
>> Since non-CURIE values MUST be ignored, ...
>>
>> becomes this:
>>
>> Since non-CURIE values MUST be ignored when they appear in safe CURIEs,
>> ...
>>
>> In section 5.4.4, after the bullet-points, the entire sentence reading:
>>
>> Note that unlike @about and @resource, @rel and @rev do not
>> differentiate their two
>> types of data by using [safe CURIE]s.
>>
>> should be removed. The next sentence, which reads:
>>
>> Instead, any value that matches an entry in the list of link types
>> in the section
>> The rel attribute, MUST be treated as if it was a URI within the
>> XHTML vocabulary,
>> and all other values must be CURIEs.
>>
>> should be changed to:
>>
>> Any value that matches an entry in the list of link types in the
>> section The rel
>> attribute, MUST be treated as if it was a URI within the XHTML
>> vocabulary. All
>> other values will be processed as URIorCURIEs.
>>
>> The next paragraph and its associated example, beginning:
>>
>> Note that only values in the link type list have this special behaviour,
>> ...
>>
>> can be deleted.
>>
>> In the section 5.4.5, the example can have its square brackets removed.
>>
>> In section 7, the sentence:
>>
>> Since it is difficult to distinguish between CURIEs and URIs, the CURIE
>> syntax adds the notion of a [safe CURIE].
>>
>> should be changed to:
>>
>> A URI that uses a scheme that is not an in-scope mapping cannot be
>> confused with a CURIE. However, since there may be situations where
>> authors would like to make it explicit that they are using a CURIE, the
>> CURIE syntax adds the notion of a [safe CURIE].
>>
>>
>> EXAMPLES
>>
>> At the end of section 2.2, we can add:
>>
>> When dealing with small amounts of mark-up, it is sometimes easier
>> to use full URIs,
>> rather than CURIEs. The previous example can also be written as follows:
>>
>> <html xmlns="http://www.w3.org/1999/xhtml">
>> <head>
>> <title>Books by Marco Pierre White</title>
>> </head>
>> <body>
>> I think White's book
>> '<span
>> about="urn:ISBN:0091808189"
>> typeof="http://example.org/book"
>> property="http://purl.org/dc/elements/1.1/title"
>> >Canteen Cuisine</span>'
>> is well worth getting since although it's quite advanced stuff, he
>> makes it pretty easy to follow. You might also like
>> <span
>> about="urn:ISBN:1596913614"
>> typeof="http://example.org/book"
>> property="http://purl.org/dc/elements/1.1/description"
>> >White's autobiography</span>.
>> </body>
>> </html>
>>
>> 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)
>>
>
>

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Proposal for 'URIs everywhere'

2009-11-26T04:30:45Z

Hi,

here's a high-level comment without looking at the details.

I appreciate the attempt to make progress. As far as I can tell, the
change being proposed actually will not be backwards-compatible in all
cases (for instance, when changing from URIorSafeCURIE to URIorCURIE).
In which case you really should consider making a change that at least
avoids confusion and potential ambiguity, by making everything
URIorSafeCURIE. That would also align (as far as I recall) with the TAG
advice not to use CURIEs where they might be confused with URIs.

Best regards, Julian

Mark Birbeck wrote:

> Hello all,
>
> I'd hoped to get the following proposal to the group at the beginning
> of the week, but it wasn't possible.
>
> Anyway, below you'll find a series of minor changes that I feel would
> need to be made to various parts of the syntax document, in order to
> support URIs and CURIEs in all RDFa-related attributes (except @src
> and @href).
>
> To recap, whilst most of our attributes support URIs and CURIEs
> already, @property, @rel and @rev only supported URIs. This means that
> authors must declare prefix mappings for all predicates, even though
> they are not required to use prefix mappings for subjects or objects.
> We've agreed to try to address this, and I had an action item to come
> up with some proposed text.
>
>
> APPROACH
>
> The first step in sorting this out, is to remove the separation where
> in some places we allow a CURIE, and in others we allow a
> URIorSafeCURIE.
>
> Both situations will now use the same type, which I've called
> 'URIorCURIE'. (This type did used to exist in previous drafts, but I
> think that's ok. Of course, if anyone can spot a reason why we should
> use a different name, then please mention it.)
>
> After making the data type consistent throughout, we then need to
> clarify the processing rules.
>
> And finally, we need to add one or more examples of using a full URI
> for a predicate.
>
>
> DATATYPE
>
> The datatype changes affect section 2.1, as follows:
>
> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
> with 'URIorCURIE'.
> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.
>
> Also, in section 5.4.4, the bullet-points listing the attributes
> should change to this:
>
> * @about, @datatype, @property, @resource and @typeof support either a URI or
> a CURIE.
> * @href and @src support only a URI.
> * @rel and @rev support XHTML link types, URIs and CURIEs.
>
>
> PROCESSING
>
> In section 5.4.2, after the three steps, but before the note, we should add:
>
> Note that this algorithm assumes that its input is a CURIE, but in practice it
> won't be possible to definitively establish this until step 2; if
> there is no in-scope
> mapping that matches the prefix, then the algorithm should terminate, and the
> input regarded as a URI.
>
> In section 5.4.3, the first point should be removed, and in the second
> point, the sentence:
>
> In this case any value that is not surrounded by square brackets, as defined
> by 'safe_curie' in the section CURIE Syntax Definition, will be
> processed as if
> it was a URI.
>
> should be changed to:
>
> In this case any value that is not a CURIE, as outlined in section 5.4.2, will
> be processed as a URI.
>
> Note that I've left the prose about square brackets intact, because
> there are probably use-cases where people want to say 'safe CURIE or
> nothing'. (I.e., don't fall back to a URI if there is no prefix
> mapping.)
>
> In the sentence after the two (now one) sentences, we should change this:
>
> An example of an attribute that can contain CURIE and non-CURIE values is
> @about. As described, any CURIEs expressed in the attribute must follow the
> format of a [safe CURIE]. So to express a URI directly, an author
> might do this:
>
> to this:
>
> An example of an attribute that can contain a URIorCURIE is @about. To
> express a URI directly, an author might do this:
>
> After the example, the next sentence/example combination can be
> duplicated, to give us an extra example, like this:
>
> whilst to express a CURIE they could do this:
>
> <div about="dbr:Albert_Einstein">
> ...
> </div>
>
> The author could also use a safe CURIE, as follows:
>
> <div about="[dbr:Albert_Einstein]">
> ...
> </div>
>
> In the next example, we just need to clarify that we're now only
> referring to safe CURIEs; this:
>
> Since non-CURIE values MUST be ignored, ...
>
> becomes this:
>
> Since non-CURIE values MUST be ignored when they appear in safe CURIEs, ...
>
> In section 5.4.4, after the bullet-points, the entire sentence reading:
>
> Note that unlike @about and @resource, @rel and @rev do not
> differentiate their two
> types of data by using [safe CURIE]s.
>
> should be removed. The next sentence, which reads:
>
> Instead, any value that matches an entry in the list of link types
> in the section
> The rel attribute, MUST be treated as if it was a URI within the
> XHTML vocabulary,
> and all other values must be CURIEs.
>
> should be changed to:
>
> Any value that matches an entry in the list of link types in the
> section The rel
> attribute, MUST be treated as if it was a URI within the XHTML vocabulary. All
> other values will be processed as URIorCURIEs.
>
> The next paragraph and its associated example, beginning:
>
> Note that only values in the link type list have this special behaviour, ...
>
> can be deleted.
>
> In the section 5.4.5, the example can have its square brackets removed.
>
> In section 7, the sentence:
>
> Since it is difficult to distinguish between CURIEs and URIs, the CURIE
> syntax adds the notion of a [safe CURIE].
>
> should be changed to:
>
> A URI that uses a scheme that is not an in-scope mapping cannot be
> confused with a CURIE. However, since there may be situations where
> authors would like to make it explicit that they are using a CURIE, the
> CURIE syntax adds the notion of a [safe CURIE].
>
>
> EXAMPLES
>
> At the end of section 2.2, we can add:
>
> When dealing with small amounts of mark-up, it is sometimes easier
> to use full URIs,
> rather than CURIEs. The previous example can also be written as follows:
>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <title>Books by Marco Pierre White</title>
> </head>
> <body>
> I think White's book
> '<span
> about="urn:ISBN:0091808189"
> typeof="http://example.org/book"
> property="http://purl.org/dc/elements/1.1/title"
> >Canteen Cuisine</span>'
> is well worth getting since although it's quite advanced stuff, he
> makes it pretty easy to follow. You might also like
> <span
> about="urn:ISBN:1596913614"
> typeof="http://example.org/book"
> property="http://purl.org/dc/elements/1.1/description"
> >White's autobiography</span>.
> </body>
> </html>
>
> 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)
>

From forum: w3.org - public-rdf-in-xhtml-tf

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

2009-11-26T03:25:58Z

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

From forum: w3.org - public-rdf-in-xhtml-tf

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

2009-11-25T16:17:41Z

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

From forum: w3.org - public-rdf-in-xhtml-tf

Proposal for 'URIs everywhere'

2009-11-25T14:06:20Z

Hello all,

I'd hoped to get the following proposal to the group at the beginning
of the week, but it wasn't possible.

Anyway, below you'll find a series of minor changes that I feel would
need to be made to various parts of the syntax document, in order to
support URIs and CURIEs in all RDFa-related attributes (except @src
and @href).

To recap, whilst most of our attributes support URIs and CURIEs
already, @property, @rel and @rev only supported URIs. This means that
authors must declare prefix mappings for all predicates, even though
they are not required to use prefix mappings for subjects or objects.
We've agreed to try to address this, and I had an action item to come
up with some proposed text.

APPROACH

The first step in sorting this out, is to remove the separation where
in some places we allow a CURIE, and in others we allow a
URIorSafeCURIE.

Both situations will now use the same type, which I've called
'URIorCURIE'. (This type did used to exist in previous drafts, but I
think that's ok. Of course, if anyone can spot a reason why we should
use a different name, then please mention it.)

After making the data type consistent throughout, we then need to
clarify the processing rules.

And finally, we need to add one or more examples of using a full URI
for a predicate.

DATATYPE

The datatype changes affect section 2.1, as follows:

1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
with 'URIorCURIE'.
2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.

Also, in section 5.4.4, the bullet-points listing the attributes
should change to this:

* @about, @datatype, @property, @resource and @typeof support either a URI or
a CURIE.
* @href and @src support only a URI.
* @rel and @rev support XHTML link types, URIs and CURIEs.

PROCESSING

In section 5.4.2, after the three steps, but before the note, we should add:

Note that this algorithm assumes that its input is a CURIE, but in practice it
won't be possible to definitively establish this until step 2; if
there is no in-scope
mapping that matches the prefix, then the algorithm should terminate, and the
input regarded as a URI.

In section 5.4.3, the first point should be removed, and in the second
point, the sentence:

In this case any value that is not surrounded by square brackets, as defined
by 'safe_curie' in the section CURIE Syntax Definition, will be
processed as if
it was a URI.

should be changed to:

In this case any value that is not a CURIE, as outlined in section 5.4.2, will
be processed as a URI.

Note that I've left the prose about square brackets intact, because
there are probably use-cases where people want to say 'safe CURIE or
nothing'. (I.e., don't fall back to a URI if there is no prefix
mapping.)

In the sentence after the two (now one) sentences, we should change this:

An example of an attribute that can contain CURIE and non-CURIE values is
@about. As described, any CURIEs expressed in the attribute must follow the
format of a [safe CURIE]. So to express a URI directly, an author
might do this:

to this:

An example of an attribute that can contain a URIorCURIE is @about. To
express a URI directly, an author might do this:

After the example, the next sentence/example combination can be
duplicated, to give us an extra example, like this:

whilst to express a CURIE they could do this:

<div about="dbr:Albert_Einstein">
...
</div>

The author could also use a safe CURIE, as follows:

<div about="[dbr:Albert_Einstein]">
...
</div>

In the next example, we just need to clarify that we're now only
referring to safe CURIEs; this:

Since non-CURIE values MUST be ignored, ...

becomes this:

Since non-CURIE values MUST be ignored when they appear in safe CURIEs, ...

In section 5.4.4, after the bullet-points, the entire sentence reading:

Note that unlike @about and @resource, @rel and @rev do not
differentiate their two
types of data by using [safe CURIE]s.

should be removed. The next sentence, which reads:

Instead, any value that matches an entry in the list of link types
in the section
The rel attribute, MUST be treated as if it was a URI within the
XHTML vocabulary,
and all other values must be CURIEs.

should be changed to:

Any value that matches an entry in the list of link types in the
section The rel
attribute, MUST be treated as if it was a URI within the XHTML vocabulary. All
other values will be processed as URIorCURIEs.

The next paragraph and its associated example, beginning:

Note that only values in the link type list have this special behaviour, ...

can be deleted.

In the section 5.4.5, the example can have its square brackets removed.

In section 7, the sentence:

Since it is difficult to distinguish between CURIEs and URIs, the CURIE
syntax adds the notion of a [safe CURIE].

should be changed to:

A URI that uses a scheme that is not an in-scope mapping cannot be
confused with a CURIE. However, since there may be situations where
authors would like to make it explicit that they are using a CURIE, the
CURIE syntax adds the notion of a [safe CURIE].

EXAMPLES

At the end of section 2.2, we can add:

When dealing with small amounts of mark-up, it is sometimes easier
to use full URIs,
rather than CURIEs. The previous example can also be written as follows:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Books by Marco Pierre White</title>
</head>
<body>
I think White's book
'<span
about="urn:ISBN:0091808189"
typeof="http://example.org/book"
property="http://purl.org/dc/elements/1.1/title"
>Canteen Cuisine</span>'
is well worth getting since although it's quite advanced stuff, he
makes it pretty easy to follow. You might also like
<span
about="urn:ISBN:1596913614"
typeof="http://example.org/book"
property="http://purl.org/dc/elements/1.1/description"
>White's autobiography</span>.
</body>
</html>

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)

From forum: w3.org - public-rdf-in-xhtml-tf

WCCM / APCOM2010 Mini-Symposium on Computational Methods in Image Processing and Analysis

2009-11-23T12:42:01Z

Image Processing and Visualization

-------------------------------------------------------------------------------------------------------------------------------

(Apologies for cross-posting)

Mini-Symposium on Computational Methods in Image Processing and Analysis

WCCM / APCOM2010 - 9th World Congress on Computational Mechanics &

4th Asian Pacific Congress on Computational Mechanics in 2010

19-23 July, 2010, Sydney, Australia

http://wccm2010.com

We would appreciate if you could distribute this information by your colleagues and co-workers.

-------------------------------------------------------------------------------------------------------------------------------

Dear Colleague,

Within the WCCM / APCOM2010 - 9th World Congress on Computational Mechanics and 4th Asian Pacific Congress on Computational Mechanics in 2010 (http://wccm2010.com), to be held in Sydney, Australia, on 19-23 July, 2010, we are organizing the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”.

Due to your research activities in the related fields, we would like to invite you to submit an invited abstract to our mini-symposium. Your contribution is mostly welcomed, and we would be honoured if you could accept this invitation.

TOPICS OF INTEREST (not restricted to):

- Image Processing and Analysis;

- Image Restoration, Compression, Segmentation and Description;

- Object Modelling, Tracking, Matching, Recognition and Reconstruction;

- Visual Inspection;

- 3D Vision;

- Medical Imaging;

- Simulation and Animation;

- Software Development for Image Processing and Analysis;

- High Performance Computing in Image Processing and Analysis;

- Applications of Image Processing and Analysis.

IMPORTANT DATES:

Deadline for one page abstracts: December 15, 2009;

Acceptance of abstracts: January 30, 2010;

Deadline for draft papers for review: February 28, 2010;

Deadline for final papers: March 31, 2010.

ABSTRACT SUBMISSION:

Please go to the abstract submission page (http://wccm2010.com/authors.htm) and select the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”.

With kind regards,

João Manuel R. S. Tavares, University of Porto, Portugal, tavares@...

Renato Natal Jorge, University of Porto, Portugal, rnatal@...

Yongjie Zhang, Carnegie Mellon University, USA, jessicaz@...

Dinggang Shen, UNC-CH School of Medicine, USA, dgshen@...

(Organizers of the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”)

From forum: w3.org - www-rdf-rules

WCCM / APCOM2010 Mini-Symposium on Computational Methods in Image Processing and Analysis

2009-11-23T12:42:00Z

Image Processing and Visualization

-------------------------------------------------------------------------------------------------------------------------------

(Apologies for cross-posting)

Mini-Symposium on Computational Methods in Image Processing and Analysis

WCCM / APCOM2010 - 9th World Congress on Computational Mechanics &

4th Asian Pacific Congress on Computational Mechanics in 2010

19-23 July, 2010, Sydney, Australia

http://wccm2010.com

We would appreciate if you could distribute this information by your colleagues and co-workers.

-------------------------------------------------------------------------------------------------------------------------------

Dear Colleague,

TOPICS OF INTEREST (not restricted to):

- Image Processing and Analysis;

- Image Restoration, Compression, Segmentation and Description;

- Object Modelling, Tracking, Matching, Recognition and Reconstruction;

- Visual Inspection;

- 3D Vision;

- Medical Imaging;

- Simulation and Animation;

- Software Development for Image Processing and Analysis;

- High Performance Computing in Image Processing and Analysis;

- Applications of Image Processing and Analysis.

IMPORTANT DATES:

Deadline for one page abstracts: December 15, 2009;

Acceptance of abstracts: January 30, 2010;

Deadline for draft papers for review: February 28, 2010;

Deadline for final papers: March 31, 2010.

ABSTRACT SUBMISSION:

Please go to the abstract submission page (http://wccm2010.com/authors.htm) and select the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”.

With kind regards,

João Manuel R. S. Tavares, University of Porto, Portugal, tavares@...

Renato Natal Jorge, University of Porto, Portugal, rnatal@...

Yongjie Zhang, Carnegie Mellon University, USA, jessicaz@...

Dinggang Shen, UNC-CH School of Medicine, USA, dgshen@...

(Organizers of the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”)

From forum: w3.org - www-rdf-logic

WCCM / APCOM2010 Mini-Symposium on Computational Methods in Image Processing and Analysis

2009-11-23T12:42:00Z

Image Processing and Visualization

-------------------------------------------------------------------------------------------------------------------------------

(Apologies for cross-posting)

Mini-Symposium on Computational Methods in Image Processing and Analysis

WCCM / APCOM2010 - 9th World Congress on Computational Mechanics &

4th Asian Pacific Congress on Computational Mechanics in 2010

19-23 July, 2010, Sydney, Australia

http://wccm2010.com

We would appreciate if you could distribute this information by your colleagues and co-workers.

-------------------------------------------------------------------------------------------------------------------------------

Dear Colleague,

TOPICS OF INTEREST (not restricted to):

- Image Processing and Analysis;

- Image Restoration, Compression, Segmentation and Description;

- Object Modelling, Tracking, Matching, Recognition and Reconstruction;

- Visual Inspection;

- 3D Vision;

- Medical Imaging;

- Simulation and Animation;

- Software Development for Image Processing and Analysis;

- High Performance Computing in Image Processing and Analysis;

- Applications of Image Processing and Analysis.

IMPORTANT DATES:

Deadline for one page abstracts: December 15, 2009;

Acceptance of abstracts: January 30, 2010;

Deadline for draft papers for review: February 28, 2010;

Deadline for final papers: March 31, 2010.

ABSTRACT SUBMISSION:

Please go to the abstract submission page (http://wccm2010.com/authors.htm) and select the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”.

With kind regards,

João Manuel R. S. Tavares, University of Porto, Portugal, tavares@...

Renato Natal Jorge, University of Porto, Portugal, rnatal@...

Yongjie Zhang, Carnegie Mellon University, USA, jessicaz@...

Dinggang Shen, UNC-CH School of Medicine, USA, dgshen@...

(Organizers of the Mini-Symposium on “Computational Methods in Image Processing and Analysis - MS9031”)

From forum: w3.org - www-rdf-interest

CFP Special Issue of the Journal of Web Semantics on Semantic Web Dynamics

2009-11-23T02:27:43Z

Apologies for the inevitable multiple receptions.

========================================

PRELIMINARY CALL FOR PAPERS

Journal of Web Semantics

Special Issue on Semantic Web Dynamics

========================================

Description

-----------

Recent years have witnessed the arrival of more and more semantically annotated data and related ontologies in the Semantic Web. For example, the linked data initiative has been very successful in making datasets available online, with a total of about 5 billion triples all together so far. While existing semantic tools and reasoning engines are year after year getting better in dealing with time invariant domain of ontological knowledge, supporting rapidly changing information has not yet attracted sufficient attention.

There are more and more heterogeneous and/or dynamic data types being created and which integration could lead to interesting applications and models (e.g. sensor data streams, geospatial information and imagery, financial transactions, news feeds, 3D models, engineering data, information for policy intelligence etc.). Current Stream Database Management Systems provide on the fly analysis of data streams, but they suffer several limitations: they cannot handle heterogeneous data streams originating from a variety of already deployed sensors; they cannot combine data streams with slowly evolving knowledge at query time; and they cannot perform reasoning tasks. And in the area of reasoning, while the problem of classical, time invariant domain of ontological knowledge has been extensively studied, the task of reasoning with rapidly changing information has been mostly neglected and constitutes a new challenge.

Furthermore, ontologies, just like any structure holding knowledge and information, need to be updated too: changes could be initiated because of a change in the world being modelled; or by a change in the users’ needs which would require a different conceptualization; or by the acquisition of knowledge previously unknown, unclassified or otherwise unavailable; or by the noticing of a design flaw in the original conceptualization. In all these cases, the representation of knowledge in the ontology should be modified so as to form a more accurate or adequate conceptualization of the domain.

This general issue of Semantic Web Dynamics includes difficulties from both practical and theoretical points of view, raising a variety of research questions and development challenges, such as how to support the ontology and data publishers in maintaining up-to-date, adequate representations; how to detect the need for evolution and changes; how to facilitate the integration of new, dynamic sources in existing datasets and ontologies; how to validate and evaluate the impact of the changes on semantic information; how to handle changes triggered from multiple sources and collaborative updates; and how to keep track of (possibly

concurrent) versions of and ensure the delivery of up-to-date and valid knowledge.

Topics of Interest

------------------

For this special issue, we seek articles describing foundational and theoretical work as well as technological solutions to these challenges.

More specifically, we expect submission on (but not restricted to) the following topics:

• Foundational and formal aspects of Semantic Web dynamics

• Language extensions for Semantic Web dynamics

• Reasoning with dynamic data and ontologies

• Engineering dynamic data and ontologies

• Requirements and practical issues for Semantic Web dynamics

• Applications of dynamic data and ontologies

• Theory for stream reasoning

• Logic language for stream reasoning

• Scalability issues in stream reasoning

• Ontologies for dynamic environments

• Dynamic knowledge building, and (re-)use

• Ontology evolution and versioning

• Language extensions for evolution

• Belief revision for ontologies

• Change propagation in ontologies dynamic datasets and ontologies

• Inconsistency in evolving semantic information

• Incremental reasoning

• Case studies and applications of ontology and knowledge evolution

• Tools to support dynamic data and ontologies

Important Dates

---------------

31 May 2010: Submission deadline

31 August 2010: First-round reviews complete

31 October 2010: Revised papers submitted

23 December 2010: Final acceptance decisions

Method of Submission

--------------------

Only electronic submissions will be considered. The precise method will be announced later. Any question can be addressed to the guest editors.

Guest Editors

-------------

Grigoris Antoniou (FORTH, Greece)

Mathieu d’Aquin (The Open University, United Kingdom)

Jeff Z. Pan (University of Aberdeen, United Kingdom)

The University of Aberdeen is a charity registered in Scotland, No SC013683.

From forum: w3.org - www-rdf-rules

CFP Special Issue of the Journal of Web Semantics on Semantic Web Dynamics

2009-11-23T02:23:17Z

Apologies for the inevitable multiple receptions.

========================================

PRELIMINARY CALL FOR PAPERS

Journal of Web Semantics

Special Issue on Semantic Web Dynamics

========================================

Description

-----------

concurrent) versions of and ensure the delivery of up-to-date and valid knowledge.

Topics of Interest

------------------

For this special issue, we seek articles describing foundational and theoretical work as well as technological solutions to these challenges.

More specifically, we expect submission on (but not restricted to) the following topics:

• Foundational and formal aspects of Semantic Web dynamics

• Language extensions for Semantic Web dynamics

• Reasoning with dynamic data and ontologies

• Engineering dynamic data and ontologies

• Requirements and practical issues for Semantic Web dynamics

• Applications of dynamic data and ontologies

• Theory for stream reasoning

• Logic language for stream reasoning

• Scalability issues in stream reasoning

• Ontologies for dynamic environments

• Dynamic knowledge building, and (re-)use

• Ontology evolution and versioning

• Language extensions for evolution

• Belief revision for ontologies

• Change propagation in ontologies dynamic datasets and ontologies

• Inconsistency in evolving semantic information

• Incremental reasoning

• Case studies and applications of ontology and knowledge evolution

• Tools to support dynamic data and ontologies

Important Dates

---------------

31 May 2010: Submission deadline

31 August 2010: First-round reviews complete

31 October 2010: Revised papers submitted

23 December 2010: Final acceptance decisions

Method of Submission

--------------------

Only electronic submissions will be considered. The precise method will be announced later. Any question can be addressed to the guest editors.

Guest Editors

-------------

Grigoris Antoniou (FORTH, Greece)

Mathieu d’Aquin (The Open University, United Kingdom)

Jeff Z. Pan (University of Aberdeen, United Kingdom)

The University of Aberdeen is a charity registered in Scotland, No SC013683.

From forum: w3.org - www-rdf-logic

ICML 2010 Call for Tutorial Proposals

2009-11-21T15:00:08Z

ICML-2010 Call for Tutorials

The ICML-2010 Organizing Committee invites proposals for tutorials to
be held at the 27th International Conference on Machine Learning, on
Monday, June 21, 2010 in Haifa, Israel (http://www.icml2010.org).

We seek proposals for tutorials on core techniques and areas of
knowledge that enjoy broad interest within the machine learning
community. We are interested in tutorials on established or emerging
research topics within the field itself, but we also welcome tutorials
from related research fields or application areas provided that they
are of sufficient interest to the machine learning community. The
ideal tutorial should attract a wide audience. It should be broad
enough to provide a gentle introduction to the chosen research area,
but it should also cover the most important contributions in depth.
Proposals that exclusively focus on the presenters' own work or
commercial presentations are not eligible.

Guidelines for preparing a proposal can be found at:
http://www.icml2010.org/tutorials.html

Tutorial proposals should be submitted via email in PDF format to
tutorials@... . Soon after submission, proposers should
expect to receive a verification of receipt.

The timeline is as follows:

* Tutorial proposals due: February 13, 2010
* Acceptance notification: February 28, 2010
* Website due: March 15, 2010
* Tutorial material due: May 30, 2010
* Tutorials date: June 21, 2010

Contact: Ben Taskar
Tutorials Chair ICML 2010

From forum: w3.org - www-rdf-logic

ICML/COLT 2010 Call for Workshop Proposals

2009-11-21T15:00:06Z

CALL FOR ICML/COLT 2010 WORKSHOP PROPOSALS

This is a call for workshop proposals for ICML & COLT 2010 in Haifa,
Israel (http://www.icml2010.org and http://www.colt2010.org).
The workshop will take place on June 25, in between ICML June 21-24
and COLT June 27-29. This two day slot presents an excellent
opportunity for you to organize a workshop on the machine
learning-related topic of your choice.

Workshop day: June 25, 2010, Haifa, Israel
Proposal deadline: Monday, January 18, 2010
Acceptance notification: Monday, February 8, 2010

Workshops are a great format for active research on new topics. The
ideal workshop covers a compelling subject of current or upcoming
research, and includes an impressive set of speakers with diverse
backgrounds to discuss the subject. Discussion via panels,
identification of open problems, or a "discussant" are all great
components to include.

Organization

The format, style, and content of accepted workshops is under the
control of the workshop organizers and largely autonomous from the main
conferences. The workshops can be up to seven hours long, split into
morning and afternoon sessions. Workshop organizers are expected to
manage the workshop content, specify the workshop format, be present to
moderate the discussion and panels, invite experts in the domain, and
maintain a website for the workshop. Workshop registration will be
handled centrally by the main conference with a single uniform
registration fee and with registrants allowed to attend workshops other
than the one they register for.

Submission Instructions

Proposals should specify clearly all of the following:

* Workshop title (what is it called?)
* Topic (what is it about?)
* Motivation (why a workshop on this topic?)
* Impact and expected outcomes (what will having the workshop do?)
* Potential list of invited speakers (who might come?)
* List of related publications (where can we learn more?)
* Main workshop organizer (who is making it happen?)
* Other organizers (who else is making it happen?)
* Bio for each organizer (who are you?)
* Workshop URL (where will interested parties get more information?)
* Relevant conferences (which of ICML and COLT would it appeal to?)

This information should be sent by email (in plain text or pdf format)
to workshops@... by January 18.

John Langford
Workshop Chair ICML 2010

From forum: w3.org - www-rdf-logic

Last CFP Agent-Directed Simulation, April 12-14, 2010, Orlando, Florida

2009-11-20T17:46:25Z

===============================================================
CALL FOR PAPERS and POSTERS
Agent-Directed Simulation Symposium (ADS'10)
Orlando, Florida, USA
April 12-14, 2010

http://www.site.uottawa.ca/~oren/conf-org/ADS_2010/ADS-CFP.htm
Manuscript Submission: November 30, 2009.

Sponsored by The Society for Modeling and Simulation
International (SCS) in collaboration with ACM/SIGSIM.
==============================================================

As part of the 2010 Spring Simulation Multi-conference (SpringSim'10)
http://www.scs.org/confernc/springsim/springsim10/springsim10.htm

the 2010 Agent-Directed Simulation Symposium is a premier platform to
explore all three aspects of the synergy of simulation and agent
technologies. Hence, it has a special place within simulation and
agent conferences, including agent-based (social) simulation
conferences. Therefore the ADS symposium fills a gap in the agent
community as well as the simulation community.

The purpose of the ADS symposium is to facilitate dissemination of the
most recent advancements in the theory, methodology, application, and
toolkits of agent-directed simulation. Agent-directed simulation is
comprehensive in the integration of agent and simulation technologies,
by including models that use agents to develop domain-specific
simulations, i.e., agent simulation (this is often referred to as
agent-based simulation -when other two important aspects are not
considered), and by also including the use of agent technology to
develop simulation techniques and toolkits that are subsequently
applied, either with or without agents.

Hence, agent-directed simulation consists of three distinct, yet
related areas that can be grouped under two categories as follows:

1. Simulation for Agents (agent simulation): simulation of agent
systems in engineering, human and social dynamics, military
applications etc.
2. Agents for Simulation (which has two aspects): agent-supported
simulation deals with the use of agents as a support facility to
enable computer assistance in problem solving or enhancing
cognitive capabilities; and agent-based simulation that focuses
on the use of agents for the generation of model behavior in a
simulation study.

Through the theme of agent-directed simulation, the symposium will
bring together agent technologies, tools, toolkits, platforms,
languages, methodologies, and applications in a pragmatic manner. In
this symposium, established researchers, educators, and students are
encouraged to come together and discuss the benefits of agent
technology in their use and application for simulation. It is a way
for people to discuss why and how they have used agent technology in
their simulations, and describe the benefit of having done so.

The theme of ADS'10 is based on the observation of the following
premises.

* The growth of new advanced distributed computing standards along
with the rapid rise of e-commerce are providing a new context that
acts as a critical driver for the development of next generation
systems. These standards revolve around service-oriented
technologies, pervasive computing, web-services, Grid, autonomic
computing, ambient intelligence etc. The supporting role that
intelligent agents play in the development of such systems is
becoming pervasive, and simulation plays a critical role in the
analysis and design of such systems.

* The use of emergent agent technologies at the organization,
interaction (e.g., coordination, negotiation, communication) and
agent levels (i.e. reasoning, autonomy) are expected to advance
the state of the art in various application technologies is
difficult. Using agent-supported simulation techniques for
testing complex agent systems is up and coming field.

* To facilitate bridging the gap between research and application,
there is a need for tools, agent programming languages, and
methodologies to analyze, design, and implement complex,
non-trivial agent-based simulations. Existing agent-based
simulation tools are still not mature enough to enable developing
agents with varying degrees cognitive and reasoning capabilities.

ADS'10 will provide a leading forum to bring together researchers and
practitioners from diverse simulation societies within computer science,
social sciences, engineering, business, education, human factors, and
systems engineering. The involvement of various agent-directed
simulation groups will enable the cross-fertilization of ideas and
development of new perspectives by fostering novel advanced solutions,
as well as enabling technologies for agent-directed simulation

AUTHOR GUIDE

* Technical papers provide a longer format for presenting experience
reports, research results, or descriptions of "work in progress".
They are limited to 8 pages.

* Short position papers are targeted at raising a question or framing
an issue for discussion during the symposium. Position papers are
limited to 3 pages.

* Poster presentations present an opportunity to present work in
progress and receive feedback from colleagues. A one page write-up
of the poster presentations will be included in the proceedings.

(For all, required font sizes are: min 10 pt for text and min 9 pt for
figures or references).

Papers should be submitted electronically to
http://www.softconf.com/scs/ADS10/ .
All papers will be subject to a peer-reviewing process by three program
committee members. (Please see the key dates listed below.)

FINAL PAPER SUBMISSION GUIDELINES

All prospective authors, whose papers are accepted for inclusion in the
program, will be invited to submit their position or technical papers
to ADS'10. Accepted and registered papers will be published in the
conference proceedings by the SCS. In addition, the committee will
select a set of best papers. Authors of these papers will be encouraged to
submit appropriately expanded versions of these papers for journal
publication.

KEY DATES
Nov 30, 2009: Manuscript submission
Dec 30, 2009: Notification of acceptance
Jan 20, 2010: Full Camera-ready papers
Apr 12-14, 2010: ADS'10 Symposium

General Co-Chair
Levent Yilmaz, Auburn University
Tuncer Ören, University of Ottawa
Program Co-Chair
Gregory Madey, University of Notre Dame
Maarten Sierhuis, Carnegie Mellon University, NASA Ames Research Center
Yu Zhang, Trinity University

From forum: w3.org - www-rdf-interest

Filling the Gap between Semantic Web and Model Driven Engineering: The TwoUse Toolkit

2009-11-20T03:54:50Z

http://west.uni-koblenz.de/twouse

TwoUse Toolkit is an implementation of current OMG and W3C standards for developing ontology-based
software models and model-based OWL2 ontologies.

*For Model Driven Developers*

* Describe your UML Classes using OWL2 class descriptions.
* Semantically search for classes, properties and instances in your UML model.
* Model variability using OWL2 classes
* Extent software design patterns with OWL2 class descriptions
* Transform your graphical models to OWL2 functional syntax
* Make sense of your modeling by inference explanations
* Browse classes, subclasses, properties and individuals using the Class Hierarchy Viewer and
the Entity Browser.

*For OWL Ontology Engineers*

* Graphically model OWL2 ontologies and OWL2 safe rules using OMG UML Profile for OWL and UML
Profile for SWRL.
* Graphically model OWL2 ontologies and OWL2 Safe Rules using the OWL2 Graphical Editor.
* Graphically model and store ontology design patterns as templates.
* Transform your graphical models to OWL2 functional syntax
* Write and safe SPARQL queries using the SPARQL Editor with syntax highlight.
* Specify and safe OWL2 ontologies using the OWL2 functional syntax with syntax highlight.

And coming soon:

* Validate UML Class Diagrams
* Validate BPMN model refinements
* Design Domain Specific Languages
* Extent your metamodels with OWL2 class descriptions

* Specify ontology APIs using the Agogo Editor.
* Specify ontology data translations using the MBOTL Editor.
* Write queries using:
o the SAIQL plug-in
o SPARQL-DL Functional Syntax

*Try it today*

* Get Eclipse Classic on http://www.eclipse.org/downloads/packages/
* Install TwoUse Toolkit from Update Site on
http://twouse.googlecode.com/svn/trunk/de.uniko.isweb.updatesite/
* Install the TopCased UML Editor from Update Site on
http://topcased-mm.gforge.enseeiht.fr/release/update-site3.5/
* Try the installed examples

*Examples, Documentation and More Information*

http://west.uni-koblenz.de/twouse

If you are interest in testing some of the coming soon functionalities, please contact us.

Fernando Silva Parreiras
parreiras@...
SIG Software Web
Institute for Web Science Technologies
University of Koblenz-Landau
Universitaetstrasse 1, B114
56070 Koblenz
+49 (0)261 287 2786
http://west.uni-koblenz.de

*Related Publications*

2009

Walter, Tobias; Ebert, Jürgen (2009): Combining DSLs and Ontologies using Metamodel Integration. In:
Domain-Specific Languages. Springer. Bd. 5658. S. 148-169.

Silva Parreiras, Fernando; Walter, Tobias; Staab, Steffen; Saathoff, Carsten; Franz, Thomas (2009):
APIs agogo: Automatic Generation of Ontology APIs. In: Poster & Demo Session, ESWC 2009.

Silva Parreiras, Fernando; Walter, Tobias; Staab, Steffen; Saathoff, Carsten; Franz, Thomas (2009):
APIs agogo: Automatic Generation of Ontology APIs. In: Proceedings of the 3rd IEEE International
Conference on Semantic Computing (ICSC 2009), September 14-16, 2009, Santa Clara, California, USA.
IEEE Computer Society.

Ren, Yuan; Gröner, Gerd; Lemcke, Jens; Rahmani, Tirdad; Friesen, Andreas; Zhao, Yuting; Pan, Jeff
Z.; Staab, Steffen (2009): Validating Process Refinement with Ontologies. In: Poster & Demo Session
ESWC 2009.

Ren, Yuan; Gröner, Gerd; Lemcke, Jens; Rahmani, Tirdad; Friesen, Andreas; Zhao, Yuting; Pan, Jeff
Z.; Staab, Steffen (2009): Validating Process Refinement with Ontologies. In: Int. Workshop on
Description Logics (DL).

Walter, Tobias; Silva Parreiras, Fernando; Staab, Steffen (2009): OntoDSL: An Ontology-Based
Framework for Domain-Specific Languages. In: ACM/IEEE 12th International Conference on Model Driven
Engineering Languages and Systems, 12th International Conference, MODELS 2009. Springer. Bd. 5795.
S. 408-422.

Silva Parreiras, Fernando; Pan, Jeff. Z.; Assmann, Uwe (2009): Second Workshop on Transforming and
Weaving Ontologies and Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, October 4th, Denver,
Colorado, USA. In: TWOMDE.

Silva Parreiras, Fernando; Pan, Jeff. Z.; Assmann, Uwe; Wende, Christian (2009): Model-Driven
Software Development with Ontologies. In: Tutorial at ACM/IEEE 12th International Conference on
Model Driven Engineering Languages and Systems (MoDELS 2009, October 4-9, 2009, Denver, Colorado, USA..

Gröner, Gerd; Staab, Steffen (2009): Modeling and Query Pattern for Process Retrieval in OWL. In:
Poster & Demo Session K-CAP 2009.

Walter, Tobias (2009): Combining Domain-Specific Languages and Ontology Technologies. In: MoDELS
Doctoral Symposium 2009.

Walter, Tobias; Ebert, Jürgen (2009): Combining ontology-enriched Domain-Specific Languages. In:
Proceedings of the of the Second Workshop on Transforming and Weaving Ontologies in Model Driven
Engineering (TWOMDE) at MoDELS.

Walter, Tobias; Miksa, Krzysztof; Kasztelnik, Marek; Sabina , Pawel (2009): Towards semantic
modelling of network physical devices. In: Proceedings of the of the Second Workshop on Transforming
and Weaving Ontologies in Model Driven Engineering (TWOMDE) at MoDELS.

Groener, Gerd; Staab, Steffen (2009): Modeling and Query Pattern for Process Retrieval in OWL. In:
Proceedings of 8th International Semantic Web Conference (ISWC). Nr. 5823.

Ren, Yuan; Groener, Gerd; Lemcke, Jens; Rahmani, Tirdad; Friesen, Andreas; Zhao, Yuting; Pan, Jeff
Z.; Staab, Steffen (2009): Validating Process Refinement with Ontologies. In: 5th International
Workshop on Semantic Web Enabled Software Engineering (SWESE).

Jekjantuk, Nophadol; Groener, Gerd; Pan, Jeff Z. (2009): Reasoning in Metamodeling Enabled
Ontologies. In: Proc. of 6th Int. Workshop OWL: Experiences and Directions (OWLED).

2008

Silva Parreiras, Fernando; Staab, Steffen; Schenk, Simon; Winter, Andreas (2008): Model Driven
Specification of Ontology Translations. In: Lia, Qing; Spaccapietra, Stefano; Yu, Eric: Conceptual
Modeling - ER 2008, 27th International Conference on Conceptual Modeling, Barcelona, Spain, October
23-26, 2008, Proceedings. Springer. Nr. 5231. S. 484-497.

Silva Parreiras, Fernando; Staab, Steffen; Pan, Jeff. Z.; Miksa, Krzysztof ; Kühn, Harald; Zivkovic,
Srdjan; Tinella, Stefano; Assmann, Uwe; Henriksson, Jakob (2008): Semantics for Software Modeling.
In: Sheu, Phillip ; Yu, Heather; Ramamoorthy, C. V.; Joshi, Arvind K.; Zadeh, Lotfi A.: Semantic
Computing. IEEE Press/Wiley. S. 25.

Silva Parreiras, Fernando; Pan, Jeff. Z.; Assmann, Uwe; Henriksson, Jakob (2008): First Workshop on
Transforming and Weaving Ontologies and Model Driven Engineering (TWOMDE 2008) at MoDELS 2008, 28
September, Toulouse, France. In: TWOMDE.

Silva Parreiras, Fernando; Staab, Steffen; Winter, Andreas (2008): Improving Design Patterns by
Description Logics: A Use Case with Abstract Factory and Strategy. In: Kühne, Thomas; Reisig ,
Wolfgang; Steimann, Friedrich: Modellierung 2008, 12.-14. März 2008, Berlin. GI. Nr. 127.

Gröner, Gerd; Staab, Steffen; Winter, Andreas (2008): Graph Technology and Semantic Web in Reverse
Engineering - A Comparison -. In: Proceedings of ICPC 2008 Workshop: Semantic Technologies in System
Maintenance.

2007

Silva Parreiras, Fernando; Staab, Steffen; Winter, Andreas (2007): TwoUse: Integrating UML Models
and OWL Ontologies. Institut für Informatik, Universität Koblenz-Landau. Nr. 16/2007.
Arbeitsberichte aus dem Fachbereich Informatik.

Silva Parreiras, Fernando; Staab, Steffen; Winter, Andreas (2007): On Marrying Ontological and
Metamodeling Technical Spaces. In: Proceedings of the 6th joint meeting of the European Software
Engineering Conference and the ACM SIGSOFT International Symposium on Foundations of Software
Engineering, 2007, Dubrovnik, Croatia, September 3-7. ACM Press.

From forum: w3.org - www-rdf-interest

Call for Papers/Workshop Proposals Participantion (GPC-10, UIC-10, MTPP-10, ICA3PP-10, FC-10, SMPE-10, FutureTech-10, BodyNets-10)

2009-11-20T03:40:38Z

====================================================================
** Apologies if you receive multiple copies of this announcement. **
====================================================================

Dear Colleague:

Please disseminate this message in your networks / subscribed lists.
We also take this chance to invite you contribute a paper / proposal
to these events. Thanks in advance.

-------------------------
Call for Participation:
-------------------------

1. Conference: IEEE SOCA 2009 (The IEEE International Conference on Service-Oriented Computing and Applications)
Web: http://www.iis.sinica.edu.tw/soca09
Place/Date: Taipei, Taiwan / December 14-15, 2009

---------------------------------
Call for Workshop Proposals
---------------------------------

1. Conference: GPC 2010 (The 5th International Conference on Grid and Pervasive Computing)
Web: http://gpc2010.ndhu.edu.tw/
Place/Date: Hualien, Taiwan / May 10-14, 2010
Publication: LNCS, Springer
Proposal Due: 10 December, 2009
Contact: Prof. Shi-Jim Yen (sjyen@... ); Prof. Robert C. Hsu (chh@...)

2. Conference: UIC 2010 (The 6th International Conference on Ubiquitous Intelligence Computing)
Place/Date: Xian, China / October 26-29, 2010
Publication: IEEE CS (EI indexed, IEEE Digital library)
Proposal Due: January 31, 2010
Contact: Prof. Robert C. Hsu (chh@...); Prof. Mieso Denko (denko@...)

-----------------------------
Call for Research Papers
-----------------------------

1. Conference: SMPE 2010 (The Fourth International Symposium on Security and Multimodality in Pervasive Environments)
Web: http://www.ftrg.org/smpe2010/
Place/Date: Perth, Australia / April 20-23, 2010
Publication: IEEE CS (EI indexed, IEEE Digital library)
Submission Due: November 25, 2009

2. Conference: ICA3PP 2010 (The 10th International Conference on Algorithms and Architecture for Parallel Processing)
Web: http://cse.stfx.ca/~ica3pp2010/
Place/Date: Busan, Korea / May 21-23, 2010
Publication: LNCS, Springer (EI Indexed, DBLP)
Submission Due: November 30, 2009

3. Conference: FutureTech 2010 (The 5th International Cnoference on Future Information Technology)
Web: http://www.ftrg.org/futuretech2010/
Place/Date: Busan, Korea / May 21-23, 2010
Publication: IEEE CS (EI indexed, IEEE Digital library)
Submission Due: November 30, 2009

4. Conference: ISA 2010 (The 4th International Conference on Information Security and Assurance)
UCMA 2010 (The 1st International Conference on Ubiquitous Computing and Multimedia Applications)
ACN 2010 (The 2nd International Conference on Advanced Communication and Networking)
AST 2010 (The 2nd International Conference on Advanced Science and Technology)
Web: http://www.sersc.org/ISA2010/
http://www.sersc.org/UCMA2010/
http://www.sersc.org/ACN2010/
http://www.sersc.org/AST2010/
Place/Date: Hyatt Regency Kolkata, Kolkata, India/ June 3-5, 2010
Publication: LNCS/CCIS, Springer (EI Indexed)
Submission Due: December 10, 2009

5. Conference: IET FC 2010 (The IET International Conference on Frontier Computing)
Web: http://fc2010.cs.pu.edu.tw/
Place/Date: Taichung, Taiwan / July 19-21, 2010
Publication: IET Press (EI Indexed, IEEE Digital library)
Submission Due: December 25, 2009

6. Conference: MTPP 2010 (The 2nd Russia-Taiwan Symposium on Methods and Tools of Parallel Programming Multicomputers)
Web: http://grid.chu.edu.tw/mtpp2010/
Place/Date: Vladivostok, Russia / May 17-19, 2010
Publication: LNCS, Springer (EI Indexed, DBLP)
Submission Due: January 10, 2010

7. Conference: BodyNets 2010 (The Fifth International Conference on Body Area Networks)
Web: http://www.bodynets.org/
Place/Date: Corfu Island, Greece / Spetember 10-12, 2010
Publication: LNICST (EI indexed, DBLP)
Submission Due: March 22, 2010

-------------------------
Journal Special Issues:
-------------------------

1. Journal: IEEE Transactions on CI and AI in Games
Theme: Computational Intelligence and AI in Economic and Financial Games
Guest editors: Han La Poutre, Edward Tsang, Athanasios V.Vasilakos
Submission Due: December 15 2009
Publication: Summer/Autumn 2010

2. Journal: International Journal of Ad Hoc and Ubiquitous Computing
Theme: Cloud Computing: Technologies and Services
Guest editors: Manish Parashar, Chung-Ming Huang, Jiannong Cao, Rajkumar Buyya, Robert C. H. Hsu
Submission Due: 31 January, 2010

From forum: w3.org - www-rdf-rules

Call for Papers/Workshop Proposals Participantion (GPC-10, UIC-10, MTPP-10, ICA3PP-10, FC-10, SMPE-10, FutureTech-10, BodyNets-10)

2009-11-20T03:40:36Z

From forum: w3.org - www-rdf-logic

Call for Papers/Workshop Proposals Participantion (GPC-10, UIC-10, MTPP-10, ICA3PP-10, FC-10, SMPE-10, FutureTech-10, BodyNets-10)

2009-11-20T03:40:24Z

From forum: w3.org - www-rdf-interest

Meeting minutes, 2009-11-29

2009-11-20T02:29:06Z

Minutes are at:

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

Text version below.

Ivan

----------------------

[1]W3C

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

RDF in XHTML Task Force

19 Nov 2009

[2]Agenda

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

See also: [3]IRC log

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

Attendees

Present
Manu_Sporny, Ivan_Herman, Mark_Birbeck, Ben_Adida,
Shane_McCarron, Steven_Pemberton

Regrets
Chair
Ben Adida

Scribe
ShaneM

Contents

* [4]Topics
1. [5]Test Cases
2. [6]Action Items
3. [7]Working Group Charter
* [8]Summary of Action Items
_________________________________________________________

Test Cases

we are doing these via e-mail, but there is a general topic.

<Steven> put that in the record manu

Action Items

Manu's action to confert the charter to HTML format is complete.

<benadida> -->
[9]http://www.w3.org/2009/11/12-rdfa-minutes.html#ActionSummary

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

<benadida> ACTION: Manu to convert WG Charter page to W3C charter
format [recorded in
[10]http://www.w3.org/2009/11/12-rdfa-minutes.html#action08] [DONE]

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

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

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

<scribe> --continues - nearly done

<msporny> we should accept the test cases based on the current
published rules and then change the test cases if we change the
rules in the future.

markbirbeck: original proposal said we should advise people to use
safe curies.

ivan and shane said why bother? It gets handled automatically.

Ben seems to have opened the question again. So there seems to be an
open issue. Should we encourage people to use safe curies or not?

Also, what if a prefix name is used that collides with a scheme

Steven says this is not a problem since if I meant it to be a
prefix, it will always remain a prefix

markbirbeck: if I edit that document later and am inserting a link
that now uses some new scheme that collides with prefixes I declared
ages ago, that could be an issue.

benadida: As long as the document doesnt change meaning if the
document is not edited later, it is not an issue

ivan1: the chances for something like this to occur are non-zero,
but it is so rare as to be uninteresting
... we should put in some warning

markbirbeck: we could plug all holes if we insist on a safe curie.
But if we are happy these edge cases are not a real issue, then
let's leave it

<msporny> I don't think we should ever depend on people correctly
using Safe CURIEs

<msporny> yes, I was in agreement with this direction.

ivan1: if we keep to the priority in processing that we look to see
if something is a CURIE or not, then this is backward compatible
... if we go one step further, we could have relative URIs in
@typeof

<msporny> I don't know if we should have relative URIs in @property
- I realize the use case, but it's very uncommon.

benadida: feels the use case is very rare.

<msporny> I think the reason to forbid it is because it
overcomplicates RDF.

ivan1: agrees but doesn't seem to find a reason to forbid it.

<msporny> s/RDFa\./RDFa./

benadida: RDF/XML is an example of having many ways to write the
same thing, and this makes it complicated to learn.
... if we have CURIEs and SafeCURIEs in the same datatype this is
complicated

ivan1: thinks that we have inconsistency in our rules today between
@rel and @rev vs. @about and @resource

<msporny> That said, I would be in favor of playing down Safe
CURIEs...

markbirbeck: points out that we could downplay SafeCURIEs if we
wanted too
... remarks that lately we have realized that if there is no defined
prefix, it can be easily interpreted as a URI. that means there is
less possibility for confusion.

<msporny> I haven't seen Safe CURIEs used in the wild...

benadida: if we are going this route, we should downplay the
importance of SafeCURIEs
... Wants to wait to see Mark's proposed spec text before making a
decision

<msporny> other than through somebody in this task force.

<Zakim> ShaneM, you wanted to discuss tag objections

<msporny> we might want to revisit this with the TAG based on our
new findings.

ShaneM: points out that the reason we have SafeCURIEs is that the
TAG said we cannot put CURIEs and URIs in the same attribute
... the TAG didn't want the possibility for confusion on the part of
humans, not software.

ivan1: for many people this is a stumbling block (using full URIs
instead of CURIEs)

ShaneM: we are conflating two issues

benadida: yes, but the one flows into the other
... proposes we wait for Mark's wording on this (but admits Ben is
the hold up!)

ivan1: make it clear to everyone (including the TAG) that we do not
intend to introduce this behavior for non-RDFa attributes such as
@href and @src

markbirbeck: we can consider this as an RDF interpretation of
existing markup

Steven: w.r.t. Ivan's remark Steven thinks if we do this people are
going to expect it to work in @href and @src. The advantage of
having two different notations

<msporny> We're going to get severe push-back from HTML WG if we
change @href and @src

is that you KNOW it was not allowed in @href. Validation might spot
an error today. Going forward there is no way that validation would
catch the use of a CURIE in @href and @src

benadida: But the browsers would not do it right... so page authors
would notice immediately that their links didn't work

ShaneM: at least if there is a SafeCURIE in @resource I would not be
confused into thinking it was a URI.

markbirbeck: That's not the point. The point is that a consumer
might think that @href=SafeCURIE should woirk. and going forward
@href=CURIE should work. And they won't!
... perhaps we should cross this bridge when we come to it.
... the reason this is back on the agenda is because of HTML5. And
this change (full URIs just work) will help us get past the
technical objection that some in the HTML5 community have raised.

Steven: The issue isn't that we can say "we won't apply this to
@href and @src" but that might not be compelling

benadida: I dont see browser manufacturers implementing
interpretation of CURIEs in @href and @src

<msporny> We should ask the TAG directly.

<msporny> I also think that the danger that Steven has outlined does
exist...

<msporny> If there is a chance of surprising somebody with this
change, I think it would be best to point it out.

ivan1: we should ensure that if we are moving in this direction we
inform the objectors to CURIEs that there will be this option in the
next version.

ShaneM: I personally would object to a change that permits CURIEs in
places where we only permits SafeCURIEs

benadida: thinks we ar econverging

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

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

<msporny> I haven't done that yet

I did this.
[13]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009N
ov/0043.html

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

<scribe> --done

<msporny> Thanks Shane :)

<scribe> ACTION: Ben to finish authoring RDFa WG charter. [recorded
in [14]http://www.w3.org/2009/10/22-rdfa-minutes.html#action07]
[DONE]

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

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

<scribe> ACTION: Shane to re-draft XMLLiteral errata text [recorded
in [17]http://www.w3.org/2009/10/15-rdfa-minutes.html#action04]
[DONE]

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

<benadida> consider thew new XMLLiteral errata text:
[18]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009N
ov/0044.html

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

<benadida> +1

<markbirbeck> +1

+1 (obviously)

<Steven> +1

<benadida> RESOLVED to accept the XMLLiteral errata text

<benadida> consider the _ prefix errata text:
[19]http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009N
ov/0043.html

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

<benadida> +1

<Steven> +1

+1

ivan1: why "SHOULD NOT" instead of "MUST NOT" for authors

<ivan1> +1

ShaneM: I have never seen a spec where we said "MUST NOT" to a spec
author

<benadida> RESOLVED to accept the _ prefix errata text

<markbirbeck> Abstaining. :)

<markbirbeck> I have use-cases for redefining '_', but they're a
little esoteric.

Working Group Charter

ivan1: I made some edits and initiated some discussion within the
W3C (management team etc.)
... for the time being it seems fine. Mike Smith suggested we make
the Javascript API a higher priority.
... If everything goes well this week or monday we will let the AC
know we are planning to move ahead with this charter.

<ivan1> [20]http://www.w3.org/2009/11/rdfa-wg-charter.html

[20] http://www.w3.org/2009/11/rdfa-wg-charter.html

ivan1: ... removed text that would cause people to be concerned
about the open-endedness of the charter. The charter has specific
deliverables. That should help assuage concerns about open-endedness

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

Steven: notes that we list coordination with external groups when
they are outside of W3C.

<Steven> Here is the ODF TC link -
[22]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=offic
e

[22] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

ivan1: pushed out milestones by a month because it assumed we would
start in January, and that was not going to happen
... we could stretch the deliverables out to make it easier.

benadida: the draft plans for slack time by having the schedule
tight, but has the end of the charter out a little bit

ivan1: we can extend the charter if we need to when deadlines are
missed. dont' need to build in slack in this way.
... some deliverables in the charter look like software development.
W3C working groups do not develop software. also, it looks like that
is what the group would be doing in its last 8 months. that might be
bad.

Steven: discussed the charter with the Interaction Domain team
group. They felt we should be doing work on some basic set of
advised vocabularies as a way to help people start using RDFa more
quickly.
... Suggests we say we will produce a cookbook or produce standard
vocabularies

ivan1: vocabularies is not an RDFa issue. it is a semweb issue. this
group should not pick it up.
... having something that is richer than the Primer (e.g., a
Cookbook) that uses some of the vocabs out there as examples might
be a real benefit. We should not be blessing vocabs.

<markbirbeck> +1 to Ivan

Steven: I think a cookbook / examples is just fine and will help
address their problem.

ShaneM: +1 to Ivan

ivan1: RDFa is a serialization syntax - vocab to use is a general
sem web issue.

re: software development...

benadida: understands w3c is not in the software implementation
business. However, when we started building prototypes of RDFa
things really moved ahead.
... if we shouldn't put them in the charter that's one thing. but we
should still prototype to ensure that things work!

markbirbeck: not convinced things took off when we started
prototyping. The problem is that mentioning specific libraries like
jQuery or Dojo might be limiting. we should not be pushing a
specific library set. We should have something more abstract but we
should not lock ourselves in and therefore miss whatever is going to
be happening two years from now.

ivan1: +1 to Mark. moreover, saying we are adapting to jQuery or
Dojo or whatever, that is something individuals are doing to ensure
that the ideas work. It should not be a deliverable of the working
group though.
... should have in the scope and deliverables more detailed text
about community building. We have the Primer. We could do a note
about triple store. There could be a cookbook. But we could also say
that at the end of the working group we have a deliverable that is a
Note about how RDfa is used in practice and what libraries are
around at the time and how RDFa is used in the wild. This is the
'start of the art' at the time.

benadida: feels there should be implementation work, but if there is
no room for it in the charter so be it

ShaneM: is concerned that a Note at the end becomes some 'iconic
thing' that gets referred to forever even though it is immediately
out of date

ivan1: What I try to do is set up wikis for groups so that it can be
maintained over time, rather than just producing a Note. Make it
explciit that there is also a wiki so the community can keep it up
once the group ends
... knows there is already a wiki outside of w3c space.
... sem web wiki was just set up by Ivan. For the time being, in the
sem web wiki there is apointer to the existing RDFa wiki.
... 'I am not in the business of trying to rule the world'.

Summary of Action Items

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

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

[PENDING] ACTION: Manu to aggressively push review of test cases via
mailing list [recorded in
[26]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
[27]http://www.w3.org/2009/10/22-rdfa-minutes.html#action08]

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

[DONE] ACTION: Ben to finish authoring RDFa WG charter. [recorded in
[28]http://www.w3.org/2009/10/22-rdfa-minutes.html#action07]
[DONE] ACTION: Manu to convert WG Charter page to W3C charter format
[recorded in
[29]http://www.w3.org/2009/11/12-rdfa-minutes.html#action08]
[DONE] ACTION: Shane to re-draft XMLLiteral errata text [recorded in
[30]http://www.w3.org/2009/10/15-rdfa-minutes.html#action04]

[28] http://www.w3.org/2009/10/22-rdfa-minutes.html#action07
[29] http://www.w3.org/2009/11/12-rdfa-minutes.html#action08
[30] http://www.w3.org/2009/10/15-rdfa-minutes.html#action04

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [31]scribe.perl version 1.135
([32]CVS log)
$Date: 2009/11/20 10:27:15 $
_________________________________________________________

[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] 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

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Inferencing on graph patterns

2009-11-19T18:28:27Z

Ooops, sorry: I realise just now that you were talking about OWL2 *RL*.
I don't have a full picture of OWL2 RL, but: if OWL2 RL allows for
recursive rules, then again SPARQL can not encode it due to a data
complexity argument - linear time lower bound for recursive rules as
opposed to AC0 (sub-linear and sub-logspace) upper bound for SPARQL.
cheers
--e.

On 20 Nov 2009, at 02:20, Enrico Franconi wrote:

> On 14 Nov 2009, at 11:41, Simon Reinhardt wrote:
>
>>> Note, however, that you may get what you want with a different
>>> query.
>>> For example, in this case, the
>>> SELECT ?type WHERE { ex:C1 rdfs:subclass ?type. }
>>> will return all possible types.
>>
>> Ok. Querying for inferred types was just an example, the initial
>> use case that brought me to this was actually a bit more complex
>> (property restrictions). For this that kind of inferencing would
>> have made the query a lot simpler. But it should still be possible
>> to cover a lot of the inferencing "rules" with SPARQL, especially
>> with property paths. Maybe it's worth investigating at some point
>> how much of OWL 2 RL could be implemented with pure SPARQL - and
>> what extensions would be needed to add the missing bits. But that's
>> just something to keep in mind for the future. :-)
>
> If you fix the entailment regime to RDFS, then very little of OWL2
> can be encoded in SPARQL, since it is has been shown that the
> computational complexities diverge too much. There are also simple
> counter-examples showing that it does not make sense to have an OWL2
> entailment regime in SPARQL, since you would get unsound results
> (wrt OWL2 semantics) very easily. So, really, SPARQL can hardly go
> beyond RDFS.
>
> cheers
> --e.
>
> [1] Enrico Franconi. The logic of RDF and SPARQL: a tutorial.
> Invited talk at the 25th ACM Symposium on Principles of Database
> Systems (PODS-2006), in Chicago IL, on 26-28 June 2006. <http://www.inf.unibz.it/~franconi/papers/franconi-slides-pods-2006.pdf
> >
>
>

smime.p7s (3K) Download Attachment

From forum: w3.org - public-rdf-dawg-comments

Re: Inferencing on graph patterns

2009-11-19T18:20:35Z

On 14 Nov 2009, at 11:41, Simon Reinhardt wrote:

>> Note, however, that you may get what you want with a different query.
>> For example, in this case, the
>> SELECT ?type WHERE { ex:C1 rdfs:subclass ?type. }
>> will return all possible types.
>
> Ok. Querying for inferred types was just an example, the initial use
> case that brought me to this was actually a bit more complex
> (property restrictions). For this that kind of inferencing would
> have made the query a lot simpler. But it should still be possible
> to cover a lot of the inferencing "rules" with SPARQL, especially
> with property paths. Maybe it's worth investigating at some point
> how much of OWL 2 RL could be implemented with pure SPARQL - and
> what extensions would be needed to add the missing bits. But that's
> just something to keep in mind for the future. :-)

If you fix the entailment regime to RDFS, then very little of OWL2 can
be encoded in SPARQL, since it is has been shown that the
computational complexities diverge too much. There are also simple
counter-examples showing that it does not make sense to have an OWL2
entailment regime in SPARQL, since you would get unsound results (wrt
OWL2 semantics) very easily. So, really, SPARQL can hardly go beyond
RDFS.

cheers
--e.

[1] Enrico Franconi. The logic of RDF and SPARQL: a tutorial. Invited
talk at the 25th ACM Symposium on Principles of Database Systems
(PODS-2006), in Chicago IL, on 26-28 June 2006. <http://www.inf.unibz.it/~franconi/papers/franconi-slides-pods-2006.pdf
>

smime.p7s (3K) Download Attachment

From forum: w3.org - public-rdf-dawg-comments

Re: Inferencing on graph patterns

2009-11-19T18:09:01Z

On 14 Nov 2009, at 05:30, Ivan Herman wrote:

>> Consider the following data in a store:
>>
>> (1) ex:C1 rdfs:subClassOf ex:C2 .
>> (2) :myC1 a ex:C1 .
>>
>> Now when you do the following query at the endpoint for the store:
>>
>> SELECT ?type WHERE { ?x a ex:C1 , ?type }
>>
>> and it supports the RDFS entailment regime the result would be
>> ex:C1 and
>> ex:C2 because the store would infer :myC1 to be of type ex:C2, either
>> when the data got added or on-the-fly.
>> But what if the store didn't contain triple (2) and so no data
>> about any
>> instances of those two classes? Is there any way that it could make
>> inferences about the data in the WHERE clause and therefore infer
>> that
>> ?x would be of type ex:C2 as well? I guess not since this is
>> querying by
>> matching patterns rather than "query by example". But I can see
>> various
>> uses for this. So if this is not how it's currently defined to work,
>> have you considered this?
>
> The inference regime is defined on possible solution. That indeed
> means
> that no inference is made on variables which means, as you say, that
> without the triple (2) the required results will not be returned. And
> there is no mechanism envisioned in SPARQL to achieve that.

The real "logical" reason why the answer is empty is that the ?x
variable is understood to be existential, so you are actually asking
"all the types of an object ?x if such object ?x *exists* and it is of
type ex:C1". But without (2) it is not guaranteed that such an object
*necessarily* exists, therefore the answer is empty.

> Note, however, that you may get what you want with a different query.
> For example, in this case, the
>
> SELECT ?type WHERE { ex:C1 rdfs:subclass ?type. }
>
> will return all possible types.

Well, only the one that can be inferred by the transitive closure of
rdfs:subClassOf. Indeed rdfs will never return any other type which
could be inferred by other means -- look at some examples of
inferences that will never be drawn by RDFS in the attachment.

cheers
--e.

rdfs-incompleteness.png (71K) Download Attachment
smime.p7s (3K) Download Attachment

From forum: w3.org - public-rdf-dawg-comments

Re: Job ad: Scientific Employee

2009-11-19T06:23:20Z

Dear All,

the Semantic Technology Institute at the University of Innsbruck
(Austria) is currently seeking candidates for the following positions:

PhD Researcher
Post-Doc/Senior Researcher

More Information on the job an application procedure can be found at
http://www.sti-innsbruck.at/about/jobs/

Best Regards,

Human Resources

STI Innsbruck
Technikerstraß1 21a
6020 Innsbruck
Austria

From forum: w3.org - www-rdf-logic

Re: Job ad: Scientific Employee

2009-11-19T06:23:20Z

From forum: w3.org - www-rdf-interest

Re: Job ad: Scientific Employee

2009-11-19T06:23:20Z

From forum: w3.org - www-rdf-rules

Re: Comments on SPARQL 1.1 WD 20091022

2009-11-19T05:28:58Z

On 24/10/2009 14:09, Leigh Dodds wrote:
Leigh,

Thank you for your comments.

This first published working draft contains the new areas for query that
the working group is progressing. The material will be integrated with
the the previous version of the query language to produce a single, new
document for SPARQL 1.1 Query.

Things may be a little rough in this first draft ...

Leigh Dodds wrote:
> Hi,
>
> Here are some personal comments/questions on the 22/10/2009 WD of
SPARQL 1.1.
>
> * Example in Section 2. I don't think the project expression conforms
> with grammar shown latter in the doc; missing brackets? I know this is
> still up for discussion, but thought I'd point it out

Yes - it's not consistent. The WG had not reached a conclusion on the
exact syntax at the time of publication.

> * Section 2, Syntax. re: the note about using FILTER instead of
> HAVING. Assuming I'm reading the comment correctly, I think for
> readability purposes its better to have a separate keyword (HAVING)
> rather than re-use the FILTER keyword. I think its clearer that there
> are different constraints (i.e. aggregates allowed or not) on the
> expression, and retains similarity with SQL.
>
> * Section 3. Text above example query is wrong, I think it should
> ready "from all the people that Alice knows", not "that know Alice".

Agreed.

>
> * Section 4. What is the rationale for including both a FILTER and a
> graph pattern operator for EXISTS/NOT EXISTS? If there are benefits in
> terms of expressivity or ease of implementation it would be good to be
> able to call these out in the specification.

If the working group decides to allow EXISTS/NOT EXISTS in FILTERs, then
there will be a example to illustrate the point.

> * Section 4. The NOT EXISTS and EXISTS graph pattern operators are
> described as "applying only to variables defined earlier in the
> pattern". What does "earlier" mean if a SPARQL processor can re-order
> the statements for optimization purposes? Does use of those operators
> have some impact on an implementations ability to do that?

It's loose wording to discuss the scoping of variables. "earlier" means
the pattern to the left or above of the NOT EXISTS.

>
> Cheers,
>
> L.

Andy
on behalf of the SPARQL Working Group

From forum: w3.org - public-rdf-dawg-comments

Re: Telecon Agenda - 19 November 2009, 1600 UTC

2009-11-19T05:13:39Z

I will be present this week, though I may be a few minutes late.

Steven

On Wed, 18 Nov 2009 19:18:24 +0100, Ben Adida <ben@...> wrote:

>
> Hi all,
>
> I'm working to get these agendas out earlier, so here goes. Next week,
> it *might* even happen on Tuesday!
>
> -Ben
>
> ==========
> Thursday, November 19th 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/12-rdfa-minutes.html#ActionSummary
>
> 2) Test Cases - conflicts with new recommendations? Quick discussion.
>
> 3) WG charter
>
> 4) @vocab discussion
>

From forum: w3.org - public-rdf-in-xhtml-tf

Telecon Agenda - 19 November 2009, 1600 UTC

2009-11-18T10:18:24Z

Hi all,

I'm working to get these agendas out earlier, so here goes. Next week,
it *might* even happen on Tuesday!

-Ben

==========
Thursday, November 19th 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/12-rdfa-minutes.html#ActionSummary

2) Test Cases - conflicts with new recommendations? Quick discussion.

3) WG charter

4) @vocab discussion

From forum: w3.org - public-rdf-in-xhtml-tf

Re: re-PROPOSAL: Errata text about XMLLiteral values and canonical XML

2009-11-18T09:43:29Z

> Section 5.5, step 9 reads in part "The value of the [XML literal] is a
> string created by serializing to text, all nodes that are descendants of
> the [current element], i.e., not including the element itself, and
> giving it a datatype of |rdf:XMLLiteral|." Unfortunately, the
> requirements for such a serialized string are not completely clear when
> it comes to XML Namespaces. For the avoidance of doubt, in future
> versions of the RDFa Syntax Recommendation, we expect to indicate that
> the value of the XML literal SHOULD be serialized Exclusive Canonical
> XML as defined in [XMLEXC14N]. We advise current implementations to
> start supporting this use model now, since other participants in their
> XML tool chain may expect consistent, canonical XML.

+1

-Ben

From forum: w3.org - public-rdf-in-xhtml-tf

Re: Call for Review of XHTML Test Cases 158, 160, 162, 164

2009-11-18T09:42:06Z

TC158: approved with discussion
TC160: approved with discussion
TC162: approved with discussion
TC164: approved with discussion

The discussion is what Shane brought up: we're now writing test cases
that will explicitly fail our new proposal. That means we need to
carefully think about the "junk" triples that might be generated once we
enable our new proposal, and whether these are really test cases we want.

I don't mind test case duplication. A while back, we agreed on the
principle that we would accept test cases only on the criteria that
they're valid, otherwise combining them becomes an n^2 problem :)

But if everyone else wants to merge 158 and 164, I'm also not opposed.

-Ben

From forum: w3.org - public-rdf-in-xhtml-tf

Re: URIs in @rel and @property...

2009-11-18T09:15:43Z

Many good comments and good elephant finding and hunting :)

I'm still concerned about the complexity we would be introducing in
@about and @resource when we already have safe CURIEs, meaning the use
cases are already addressed, I believe.

That said, I also see the benefit of applying the general rule of CURIE
falling back into URLS when the prefix isn't defined... that's kind of nice.

I'm not entirely sure which side I fall on right now, but if we have a
very clear algorithm that we all agree on, I guess I could be convinced
to go with this new URI-fallback mechanism.

-Ben

From forum: w3.org - public-rdf-in-xhtml-tf