Re: Publication Request Form / System

I am happy to use that vocabulary - are you all happy that URI is the
permanent home for that vocabulary?  Once we start referencing it in specs
we are stuck.

On Thursday, June 20, 2013, Alexandre Bertails wrote:

> On 06/20/2013 02:45 PM, Gregg Kellogg wrote:
>
>> On Jun 20, 2013, at 10:18 AM, Alexandre Bertails <bertails@w3.org> wrote:
>>
>>  On 06/20/2013 12:38 PM, Gregg Kellogg wrote:
>>>
>>>> On Jun 20, 2013, at 9:07 AM, Alexandre Bertails <bertails@w3.org>
>>>> wrote:
>>>>
>>>>  On 06/20/2013 12:03 PM, Gregg Kellogg wrote:
>>>>>
>>>>>> On Jun 20, 2013, at 8:36 AM, Alexandre Bertails <bertails@w3.org>
>>>>>> wrote:
>>>>>>
>>>>>>  On 06/20/2013 10:37 AM, Doug Schepers wrote:
>>>>>>>
>>>>>>>> Hi, folks-
>>>>>>>>
>>>>>>>> I have a suggestion for our publication workflow that I think would
>>>>>>>> provide clarity and consistency: a publication request form.
>>>>>>>>
>>>>>>>
>>>>>>> Already in the pipe, partially implemented and Webmaster-only for now
>>>>>>> as development is making progress and priorities are sorted out. But
>>>>>>> that's clearly the plan for the future.
>>>>>>>
>>>>>>>
>>>>>>>> This would be a form that contains all the fields needed for each
>>>>>>>> stage
>>>>>>>> of the publication process, including spec name, shortname(s), URLs
>>>>>>>> of
>>>>>>>> Editor's Draft and TR draft, abstract, WG name, WG approval to
>>>>>>>> publish,
>>>>>>>> planned publication date, news-item blurb, optional list of changes,
>>>>>>>> notes (for anything out of the ordinary), etc.
>>>>>>>>
>>>>>>>
>>>>>>> Believe me, you don't to fill these values by hand, it's highly
>>>>>>> error-prone. There is currently a service that "extracts" some of the
>>>>>>> informations from the spec, but it's a bit buggy and does not capture
>>>>>>> everything. The long-term alternative is to make the metadata
>>>>>>> available directly in the spec, could be generated by ReSpec and
>>>>>>> other
>>>>>>> tools directly. That's fairly easy, except for editors which must be
>>>>>>> bound to the database. This one would be easy if people can agree on
>>>>>>> using URLs to speak about the editors, though.
>>>>>>>
>>>>>>
>>>>>> If the doRDFa variable is set (to "1.1", I believe) in the
>>>>>> respecConfig, it ends up generating good RDFa for all of this stuff in the
>>>>>> spec. It's been optional, and only included in a couple of specs from
>>>>>> RDF-related specs AFAIK. It seems to me that there's really no downside to
>>>>>> making this the default (perhaps with an option to turn it off). This would
>>>>>> make extracting such information from the specs themselves much less error
>>>>>> prone.
>>>>>>
>>>>>
>>>>> That's interesting. I've never looked carefully at what is generated
>>>>> by ReSpec there. Can you please point me at a recent spec embedding
>>>>> some RDFa? I can have a quick sense about how much work there would be
>>>>> to make it usable on our side.
>>>>>
>>>>> Alexandre.
>>>>>
>>>>
>>>> Look in the latest version of RDFa 1.1 Core, for example. For me, this
>>>> yields the following:
>>>>
>>>
>>> Thanks, that's already a good start. If I'm not mistaken, important
>>> information is missing though, like the type of spec (REC). Also,
>>> we'll need to find a way to have stable identifiers (URLs) for the
>>> editors. That was an issue with the previous version of tr.rdf.
>>>
>>
>> Spec type would be really useful, it could as an extra type in addition
>> to bibo:Document.
>>
>> The subject of the document should probably be based on it's version URL,
>> and not the document location to. Moreover, we may want to use a fragid for
>> the document, to avoid HTTP range-14 discussions. For example:
>>
>> @base <http://www.w3.org/TR/2012/**REC-rdfa-core-20120607/<http://www.w3.org/TR/2012/REC-rdfa-core-20120607/>>
>> .
>> <#this> a bibo:Document, w3c:Recommendation;
>>    dcterms:title "RDFa Core 1.1";
>>    ...
>>
>
> For historical reasons, it would not be <#this> but <>.
>
>
>> (just made up w3c:Recommendation, perhaps there's an existing vocabulary
>> for recommendation types.)
>>
>
> It's http://www.w3.org/2001/02pd/**rec54#REC<http://www.w3.org/2001/02pd/rec54#REC>. The full vocabulary is there. It's the one used in tr.rdf.
>
> Alexandre.
>
>
> Gregg
>
>  Alexandre.
>
>
> @prefix bibo: <http://purl.org/ontology/**bibo/<http://purl.org/ontology/bibo/>>
> .
> @prefix dcterms: <http://purl.org/dc/terms/> .
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-**rdf-syntax-ns#<http://www.w3.org/1999/02/22-rdf-syntax-ns#>>
> .
> @prefix xhv: <http://www.w3.org/1999/xhtml/**vocab#<http://www.w3.org/1999/xhtml/vocab#>>
> .
> @prefix xsd: <http://www.w3.org/2001/**XMLSchema#<http://www.w3.org/2001/XMLSchema#>>
> .
>
> <> a bibo:Document;
>     dcterms:title "RDFa Core 1.1";
>     dcterms:abstract """Abstract
>        The current Web is primarily made up of an enormous number of
> documents
>          that have been created using HTML. These documents contain
> significant
>          amounts of structured data, which is largely unavailable to tools
> and
>          applications. When publishers can express this data more
> completely, and
>          when tools can read it, a new world of user functionality becomes
>          available, letting users transfer structured data between
> applications
>          and web sites, and allowing browsing applications to improve the
> user
>          experience: an event on a web page can be directly imported into a
>          user's desktop calendar; a license on a document can be detected
> so that
>          users can be informed of their rights automatically; a photo's
> creator,
>          camera setting information, resolution, location and topic can be
>          published as easily as the original photo itself, enabling
> structured
>          search and sharing.
>        RDFa Core is a specification for attributes to express structured
> data
>          in any markup language. The embedded data already available in the
>          markup language (e.g., HTML) can often be reused by the RDFa
> markup, so
>          that publishers don't need to repeat significant data in the
> document
>          content. The underlying abstract representation is RDF
> [RDF-PRIMER],
>          which lets publishers build their own vocabulary, extend others,
> and
>          evolve their vocabulary with maximal interoperability over time.
> The
>          expressed structure is closely tied to the data, so that rendered
> data
>          can be copied and pasted along with its relevant structure.
>        The rules for interpreting the data are generic, so that there is no
>          need for different rules for different formats; this allows
> authors and
>          publishers of data to define their own formats without having to
> update
>          software, register formats via a central authority, or worry that
> two
>          formats may interfere with each other.
>        RDFa shares some of the same goals with microformats [MICROFORMATS].
>          Whereas microformats specify both a syntax for embedding
> structured data
>          into HTML documents and a vocabulary of specific terms for each
>          microformat, RDFa specifies only a syntax and relies on
> independent
>          specification of terms (often called vocabularies or taxonomies)
> by
>          others. RDFa allows terms from multiple independently-developed
>          vocabularies to be freely intermixed and is designed such that the
>          language can be parsed without knowledge of the specific
> vocabulary
>          being used.
>        This document is a detailed syntax specification for RDFa, aimed at:
>
>          those looking to create an RDFa Processor, and who therefore need
> a
>            detailed description of the parsing rules;
>          those looking to integrate RDFa into a new markup language;
>          those looking to recommend the use of RDFa within their
>            organization, and who would like to create some guidelines for
> their
>            users;
>          anyone familiar with RDF, and who wants to understand more about
>            what is happening 'under the hood', when an RDFa Processor runs.
>
>         For those looking for an introduction to the use of RDFa and some
>          real-world examples, please consult the [RDFA-PRIMER].
>
>          How to Read this Document
>          First, if you are not familiar with either RDFa or RDF, and
>            simply want to add RDFa to your documents, then you may find
> the RDFa
>
>
>

-- 
Shane P. McCarron
Managing Director, Applied Testing and Technology, Inc.