RDF in XHTML Task Force

Action Items

<scribe> ACTION: Ben to author wiki page with charter template for RDFa IG. Manu to provide support where needed. [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action10] [DONE]

<scribe> ACTION: Manu to finalize RDFa IG charter template. [recorded in http://www.w3.org/2009/08/13-rdfa-minutes.html#action02]

Manu: Ben said that we should review RDFa IG charter template.

<scribe> ACTION: Shane to produce proposed diff re: XMLLiteral change [recorded in http://www.w3.org/2009/07/30-rdfa-minutes.html#action03] [CONTINUES]

Steven: RDFa IG has suggestions for RDFa 1.1
... Can an RDFa IG do RDFa 1.1?
... We would need a WG for a next version of RDFa 1.1

markbirbeck: Why don't you co-chair RDFa?

Manu: Not sure if I have the time to do so, but Ben may want this as well as he's increasingly busy these days.

<Steven> "This document defines three types of groups:

<Steven> Working Groups. Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups). There are Good Standing requirements for Working Group participation as well as additional participation requirements described in the W3C Patent Policy [PUB33].

<Steven> Interest Groups. The primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.

<Steven> Coordination Groups. A Coordination Group manages dependencies and facilitates communication with other groups, within or outside of W3C.

<Steven> http://www.w3.org/2005/10/Process-20051014/groups.html#ReqsAllGroups

Manu: We need to speak with Ralph about generating an RDFa 1.1 in an IG.

RDFa IG (review/approve charter) and Suggestions for RDFa 1.1

Manu: any other requirements for a WG?

Steven: We need a staff contact.
... Is 1 year enough?

Manu: Don't know if we want more time...

markbirbeck: I agree with Steven, we need more time

Manu: Two years, then.

markbirbeck: Should it be the embedded metadata interest group?

<Steven> It always takes longer than you expect

markbirbeck: As time moves on, we will find ourselves dealing with other types of embedded metadata.

Steven: Yes, it's good if we generalize without making it vague.

Manu: So, this group would talk about and possibly continue to standardize RDFa, Microformats, and Microdata?

markbirbeck: Maybe we should throw in Linked Data as well.
... We are not interested in SPARQL or pure RDF/XML or N3.
... We're interested in expressing metadata/RDF in HTML.
... We might want to broaden the participation.

Manu: +1 to the idea
... this wouldn't change much of the language in the charter.

Steven: I dislike the out of scope section.

markbirbeck: Yes, you're right.
... Everything else is out of scope, so why specifically mention HTML5.

http://rdfa.info/wiki/Rdfa-ig-charter

Steven: If an IG is not allowed to RDFa 1.1, we have to do a WG.

ShaneM: +1

Manu: +1

<markbirbeck> +1

Features in RDFa 1.1

Steven: Let's not discuss that - that's a task of the new WG.

Manu: Anyone else object to not talking about it?
... No objections noted, continuing on.

@profile discussion

Manu: Ben was (more or less) asking for a way to set the default prefix.
... and that would in-turn use RDF reasoning agents to figure out the proper term when refering to external vocabularies.
... What Mark is saying is that @token is for specifying mappings for CURIEs.
... Mark is asserting that loading external vocabularies is a separate discussion, but @token does apply to that discussion.

markbirbeck: There may not even be an OWL/RDFs reasoning agent behind the mapping.
... I'm trying to propose a simple mechanism for mapping URIs.
... URIs are kinda like the infrastructure... we're trying to make URIs easier to manage.

Manu: I think there is room for both a mechanism for specifying the default prefix mapping, and @token in the spec.
... I think we all agree that both setting the default prefix and @token could be a part of RDFa 1.1.
... The real issue is with how we deal with external vocabularies.

<Zakim> ShaneM, you wanted to remind that OWL is a red herring

ShaneM: You mentioned OWL - OWL is a red herring.
... You don't need OWL to say X is the same as Y... you can use RDFS to do that.
... Crafting ontologies are not for the meek.
... Having an inline mechanism for defining additional reserved words is orthogonal to this other stuff.
... If we can have an inline mechanism for defining additional reserved words, there is value in that.
... Ben wants to solve the use case of...
... How do we specify vocabularies that are easy for people to access and use?

markbirbeck: Don't know if OWL is quite a red herring - I think when we say OWL we mean RDFS...
... We're talking about mapping one property to another.
... Ben is talking about mapping properties/classes.

Manu: We may want to approach this from another direction.

Manu: Thinking about it from conformance levels might be helpful.
... RDFa Level 1 - all triples are generated from the document, no external loading.
... RDFa Level 2 - loading external vocabularies via the network is required for processor conformance.

markbirbeck: I don't know if we need to make the differentiation.
... W3C has many specs that require network access.
... We're talking about using a URI to specify a profile.
... You start with a document and then you specify fallbacks.
... Nobody said that the thing pointed to by @profile must be an RDFa document.
... It could be a JSON formatted document... you could retrieve information via that means.
... That doesn't require XMLHttpRequest...
... You could do it with Javascript and a <script> tag, for example: <script source="predefined_vocab.js" />
... You can't really do anything with the triples in Ben's proposal unless you've done the RDF schema mapping.
... We should really discuss the dereferncing mechanisms...

<Zakim> ShaneM, you wanted to discuss dereferencing

ShaneM: I don't agree with Ben's approach entirely... but you can do something with his triples.
... You can compare them if you can't retrieve the remote document.
... if you can't get the remote document, and it's never been cached before, you can't figure out what the triples mean.
... Caching requires the ability to dereference the source.
... There are security models here that is a problem.
... Requring the external mechanism makes it challenging to go forward with it.

markbirbeck: The amount of time that external referencing works outweighs the the amount of times that didn't work.
... Say it's google crawling, if they can't get the external vocabulary, they don't have a complete representation of the document.
... The big issue is with the Javascript parsers.
... There is no magic solution, but there is no magic solution for any networked architecture.

<Zakim> msporny, you wanted to discuss requiring derefernceing mechanisms

<Zakim> ShaneM, you wanted to discuss ambiguity of content when things are dereferenced vs. when they are not

Manu: This is the web - we dereference all the time.
... If in 1% of the cases, we can't dereference, so what?

ShaneM: Without a profile, terms are meaningless.

ShaneM: We also have a situation with rel="fish" and default prefix -- combine that situation with the ability to have a default prefix.
... The default prefix mechanism is only complementary when external loading works.

markbirbeck: good point.

Manu: yes, that's an issue.

ShaneM: <span defaultprefix="http://example.org/vocab#" profile="http://example.org/foo/vocab#" rel="fish" />
... if the external document foo, failed to load (which contains the mapping for fish)
ShaneM: Then the erroneous term that is generated would be http://example.org/vocab#fish" and not http://example.org/foo/vocab#fish

<ShaneM> remember that microformats dont map to triples

Manu: you can translate Microformats to triples (subjects are always bnodes).

markbirbeck: Loading default tokens for known @profiles is not a big deal.

ShaneM: yes, that is a big deal.
... if Google updates its token list, and you're loading an old one, that's a big deal.
... your triples are different.

markbirbeck: It's probably not the case that there are hundreds of vocabularies flying around.

markbirbeck: We want a generic mechanism - follow your nose that works on everything.
... But we also should be okay with people hard coding things into their parsers.
ShaneM: Remember that HTTP supports GET and HEAD - caching is relatively easy. triple stores can be cached.