RDF Web Applications Working Group Teleconference -- 28 Jul 2011

<trackbot> Date: 28 July 2011

<MacTed> (eventually someone will update trackbot to do both of those, not just the second, when it prepares a meeting...)

<Knud> good afternoon!

<MacTed> :-)

<scor> thanks MacTed

<manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0058.html

<manu1> scribenick: tomayac

need to discuss structureddata.org?

no news, continous work, but not ready for release yet

<scor> s/structureddata.org/http://structured-data.net/

tantek from microformats and phillip jagerstedt added to the repo

<scor> Henri Sivonen

and henri sivonen added to the repo

<manu1> Philip Jägenstedt

Proxy vocabularies via @vocab

<lindstream> https://gist.github.com/1092350

<manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0048.html

lindstream: talks us through https://gist.github.com/1092350

manu1: this almost looks like a reinvention of rdfa profiles. it's great, though.

<Knud> should this be part of the RDFa spec, or a separate spec (a W3C note?) that we reference?

lindstream: it grew from that. similarity is intentional.

manu1: it's a post-processing step
... wondering why not just using rdfs

<gkellogg> +1 to talk about diff with rdfs

knud: do you think this should be a part of rdfa, or a best practice?
... i don#t see this as a part of rdfa

<Zakim> gkellogg, you wanted to talk about diff with rdfs

gkellogg: this can be more generic than just rdfa
... it includes some f the rdf entailment rules
... you'll need somethin like owl:sameas
... it needs some iterations
... we probably do want something normative about it

lindstream: it would be good to publish a note apart from the rdfa spec
... there might be a need for this pattern
... not sure if it's better than mixing vocabularies, but imho it's very valuable

<Zakim> manu1, you wanted to respond directly to Knud's question

manu1: we should say something normative about it
... mapping might be done differently by google, facebook, etc.
... there's an opportunity to just get it out

knud: not yet completely convinced
... a stand-alone doc might be more useful
... facebook and google don't seem to want people to mix vocabularies, also microdata people think it'd be easier
... being able to mix vocabularies was our main motiviation to introduce profiles
... but it seems the big players don't want / need this, though

manu: more concerned about the w3c process

manu1: pushing this separately is out of charter
... we can put it in rdfa core spec, but there're also issues
... we can always publish it as a note and people can either ignore or use it

lindstream: i didn't ask to be normative about this

manu1: it'd be fine with publishing as a note

gkellogg: doing it in a non-normative way might result in everyone just doing it their way

<Zakim> ShaneM, you wanted to ask what problem are we trying to solve?

gkellogg: might lead to confusion

shanem: we came into this rdfa process with a set of use cases and a plan to address them
... if we come to the end without addressing the use cases, we should just say we don't address them

manu1: we were very concerned about vocabulary mixing

<MacTed> +1

shanem: if we come out of this without a way to do it, i feel like we have not done our job

manu1: does not be normative mean you (openlink) wouldn't put it in virtuouso

<Knud> vocabulary mixing can always be done with @prefix, right?

macted: not necessarily

manu1: would proxy vocabularies be good?

shanem: i would agree

ted: not sure what problem is being resolved

manu1: option 1 = modify prefix, 2 = use vocab, but limits to one vocabulary
... proxy vocabulary allows for mixing via a big über vocabulary

<Zakim> ShaneM, you wanted to ask for a clarification on @vocab

shanem: if i'm a semantic data processing engine, i'm gonna follow my nose
... because i don't know what a term is
... when i do that, when i see that term is a foaf:name, don't i know that automatically

manu1: in theory this is how it works

lindstream: we already have all the semantic mechanisms there
... it is more or les putting a focus on that it is possible

shanem: if the semweb isn't doing this yet, then probably they never will. who needs the hint?

lindstream: the non-hardcore engines

shanem: but they don't seem to care

lindstream: fair enough...

<Zakim> manu1, you wanted to add normative statements to @vocab

manu1: if we said normatively that you should proxy vocabularies?
... we shouldn't have to say this
... we expect people that use vocab to make sure that people can follow their nose

gkellogg: we have to remember that there's a difference between processing and reasoning
... if we ever want to have browser vendors to do stuff with this, reasoning won't be the way

<ShaneM> text from the role spec about vocabluaries: It is possible to define additional role values. Such values must be defined in their own vocabulary. The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary. One format that achieves this is the RDFa Profile as defined in [RDFA-CORE].

lindstream: since vocab is used to turn the term into a uri, you should be able to get info on what it is

<ShaneM> I am happy to add text to RDFa Core that indicates the URI for @vocab must resolve and SHOULD resolve to a resource that ... (see above)

lindstream: hardcore semweb engines follow their noses, others dont

manu1: seems like we have reached a circle here

people should understand anyways

manu1: in an ideal world

shanem: if the community is unable to use it, we have failed to explain

<ShaneM> put it in the primer

ted: we are now endlessly complicating

<Knud> isn't there a W3C document somewhere called "the self-describing web"?

<ShaneM> the sem web coord group may surprise you and point you at an existing spec that describes follow your nose

<ShaneM> http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

<Knud> yes, that

<MacTed> it just seems that we're doing s/@profile/@proxyvocab/g

<MacTed> not really changing what's happening -- just the term for it

manu1: the semweb coordination group might be a good candidate for publishing this doc

<manu1> ACTION: Manu to raise @profile and Proxy Vocabulary issue with SWCG. [recorded in http://www.w3.org/2011/07/28-rdfa-minutes.html#action01]

<trackbot> Created ACTION-88 - Raise @profile and Proxy Vocabulary issue with SWCG. [on Manu Sporny - due 2011-08-04].

<Zakim> ShaneM, you wanted to clarify whether we want language in rdfa core that indicates that a vocab should include an RDFa definition of the vocab

shanem: do you want me to put that sentence (above) in the spec?

<Knud> RDFa or other RDF?

shanem: objections? none

<ShaneM> The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary. One format that achieves this is the RDFa Profile as defined in [RDFA-CORE].

<ShaneM> RDFa Profiles are collections of terms, prefix mappings, and/or default vocabulary declarations. A profile is either intrinsically known to the parser, or it is loaded as an external document and processed. These documents must be defined in an approved RDFa Host Language (currently XML+RDFa and XHTML+RDFa [XHTML-RDFA]). They may also be defined in other formats (e.g., RDF/XML [RDF-SYNTAX-GRAMMAR], or Turtle [TURTLE]). RDFa Profiles are referenced via @profi

lindstream: i agree. it is just a uri

manu1: are we ok with removing profile entirely from rdfa core?
... with the assumption that the vocabulary stuff will be cleared

macted: we don't seem to have a clear understanding of what the problem is

knud: the problem with profile is that rdfa core requires it to be resolved
... what if it can't ?
... vocab does not have to be resolved, it can be, though

manu1: to clarify: must pre-process to may post-process

<ShaneM> not MAY pre-process. CAN post-process.

<ShaneM> And, FWIW, it was ALWAYS this way (@vocab)

<gkellogg> Without giving some guidance on /how/ to process @vocab, nothing will happen. We should have text indicating /what/ should be in the doc pointed to by @vocab with simple processing rules.

<gkellogg> A potential issue with multiple @vocab definitions is that each sub-graph needs to be processed using different rules.

manu1: we would have almost the same thing covered by profile and vocab
... both allow vocabulary mixing

shanem: you can declare prefix mappings, this wouldn't be possible in a post-process world

<manu1> PROPOSAL: Remove @profile feature from the RDFa Core specification with the caveat that the issue will be re-opened if ePub, OpenDoc, IPTC, or other communities have an issue with its removal.

<Knud> +1

<manu1> +1

<lindstream> +1

<gkellogg> +1

<MacTed> +1

<scor> +1 for removal

<bergie> +1

<ShaneM> +1

<manu1> RESOLVED: Remove @profile feature from the RDFa Core specification with the caveat that the issue will be re-opened if ePub, OpenDoc, IPTC, or other communities have an issue with its removal.

- DRAFT -

RDF Web Applications Working Group Teleconference

28 Jul 2011

Attendees

Contents

Proxy vocabularies via @vocab

Summary of Action Items

Scribe.perl diagnostic output