Re: Profiles in RDFa 1.1

Hey Mark,

I will not be at the telco (hopefully, Air France willing, I will be on my way home), but here are my reactions.

1. Out of the two solutions you propose I am pretty much against the second one. What you propose, if my understanding is correct, that the @prefix attribute on the <html> would have a dual role, depending on whether I use that document as a profile or as a straight RDFa document. I find that utterly confusing. It is also, in my view, architecturally wrong to use the same RDFa file in two different manners, depending on the context of usage (ie, just as a simple RDFa file or as a profile file). Finally, authors of such documents would have to have a different 'authoring' style for profile document: they should _not_ use the @prefix attribute in the <html> element for those prefixes that they do _not_ mean to be used as a profile information. This is also confusing.

Also, as you yourself note, it requires us either to come back to another issue that we have already decided upon, namely the different management of terms and prefixes (and the modification of the @prefix attribute's syntax, let alone the fact that the attribute name 'prefix' is then also a misnomer) or to introduce yet another syntax for terms with a @term attribute, something that did not hitherto come up as a requirement. I am not prepared to go down that road, I do not see any reason to do so.

All in all: I am sorry, but the second alternative is not acceptable to me...

2. The first approach: 

> : http://xmlns.com/foaf/0.1/
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> name http://xmlns.com/foaf/0.1/name

obviously works. I am a little bit afraid that the way terms are defined may be a bit error-prone; it may be too easy to forget the ':' character. But as we said many times, we do not expect many profile definitions around, so this may not be that of a huge deal. Implementation of this is obviously easy, a simple split on the space character does the trick (to follow the usual style, I would probably accept a '#' character at the beginning of the line as comment, b.t.w.)

So which one to choose? I must admit that I never bought your arguments against using RDF for this purpose. But you have already expressed this in other threads, so did I, and there is no need to repeat these here. Consequently, your 'pro' arguments for your solution stating 'it does not use RDF' is not compelling to me. As far I can see the main pros are:

1. Pro RDFa (ie, the current solution): possibility for a self-documented profile using RDFa, a.k.a. eating our own dog food:-). The current approach allows the mixture in one document of different things. Eg, the DC people might define their vocabulary in RDFa, but they might also define their preferred prefix in the same document, so I could use that as a profile document, too. Another typical usage is that a namespace document (that is in HTML+RDFa) can also be used as an RDFa profile (I think this is what Shane has done for XHTML). There may be several examples for such use.

2. Pro textual (ie, the one you propose below as number 1): it is obviously simple, straight to the point, and understandable by absolutely non-RDF savy authors. Your argument of an analogy to CSS files also resonates well to me.

Personally, I see more potential in #1 above. As a consequence, and I do not see any compelling reasons to change what we have, and I would vote to keep the current solution. However, if the majority of the WG decides to move to #2, I will not lie down the road either.

Ivan


On Oct 20, 2010, at 20:56 , Mark Birbeck wrote:

> Hi all,
> 
> As you know, I'm against expressing prefix and term mappings by using
> RDF directly. I've explained this in many other threads and
> discussions, so won't go through it again here. The main point of this
> email is that I've been asked to suggest an alternative.
> 
> I actually have two proposals, one that uses a simple text format and
> the other that uses an RDFa document but involves only processing
> certain attributes.
> 
> I favour supporting at least the text format, and optionally the
> HTML+RDFa format.
> 
> However, I appreciate that there is a desire to use HTML documents so
> as to be able to describe the profile, so I would have no problem if
> only the second format was supported.
> 
> 
> PROPOSAL 1: USING @PREFIX FORMAT
> 
> We already have a syntax for defining prefix mappings:
> 
> <div prefix="
>     foaf: http://xmlns.com/foaf/0.1/
>     dcterms: http://purl.org/dc/terms/
>   ">...</div>
> 
> We could easily use this for our external file format:
> 
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> 
> This follows the way that scripts and CSS work in HTML, in that the
> external version of a script or stylesheet uses the same syntax as a
> version that is embedded in the document. This means that it's very
> easy to convert from an embedded scenario to an external scenario
> because you simply take the embedded text, move it to a document and
> then reference that document.
> 
> (Our current model has a very simple way to embed prefix mappings into
> a document, but a very complicated way to embed prefixes in an
> /external/ document.)
> 
> Note that the @prefix syntax doesn't currently account for terms or
> the default vocabulary:
> 
> For the default vocabulary we could just use ':':
> 
> : http://xmlns.com/foaf/0.1/
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> 
> For terms, we can either omit the colon (note that 'name' has no colon):
> 
> : http://xmlns.com/foaf/0.1/
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> name http://xmlns.com/foaf/0.1/name
> 
> or simply remove the distinction between terms and prefix mappings
> (here 'name' does have a colon):
> 
> : http://xmlns.com/foaf/0.1/
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> name: http://xmlns.com/foaf/0.1/name
> 
> (I think it's an omission that we don't allow terms to be defined
> without a profile, and either of these two solutions might be allowed
> in the main document.)
> 
> Advantages:
> 
> * doesn't use RDF;
> * consistent with the way that scripts and stylesheets work;
> * doesn't require a full RDFa parser -- only requires the part that processes
> @prefix;
> * easy to take mappings from a document and create a profile with them,
> without having to know RDF.
> 
> Disadvantages:
> 
> * no commenting mechanism, so not self-describing.
> 
> (Of course, a commenting mechanism could easily be added!)
> 
> 
> PROPOSAL 2: PARSE @XMLNS/@PREFIX/@VOCAB ON EXTERNAL DOCUMENT
> 
> An additional/alternative proposal would be to use RDFa in the
> external document, but only take account of the @xmlns, @prefix and
> @vocab attributes.
> 
> (I'd consider ignoring @xmlns if we intend to deprecate it, but that's
> a minor issue.)
> 
> As per section 7.6 'Processing', an empty context object would be
> created at step 1, then steps 3, 4 and 13 would be applied to the
> profile document. The resulting context object would be in effect a
> 'profile' object, although only the following context object
> properties would be relevant:
> 
> * the local list of URI mappings;
> * the local term mappings;
> * the local default vocabulary.
> 
> Note that since contexts are pushed and popped then the resulting
> profile will actually be whatever is present on the <html> element of
> the profile document. I think this is acceptable, but more control
> over the layout could be achieved by making the profile 'cumulative'
> (i.e., by not pushing and popping the context). I could go either way
> on this.
> 
> Advantages:
> 
> * doesn't use RDF;
> * consistent with the way that RDFa works;
> * doesn't require a full RDFa parser -- only requires the part that processes
> @xmlns, @prefix and @vocab;
> * easy to take mappings from a document and create a profile with them,
> without having to know RDF;
> * self-describing, in that the HTML document can contain a description of the
> profile, links to resources, etc.
> 
> Disadvantages:
> 
> * there is currently no way to define a term in a document. However, I believe
> this is an omission in RDFa generally, so shouldn't be regarded as a
> limitation
> here.
> 
> 
> EXAMPLES
> 
> 1. Using @prefix syntax:
> 
> : http://xmlns.com/foaf/0.1/
> foaf: http://xmlns.com/foaf/0.1/
> dcterms: http://purl.org/dc/terms/
> name: http://xmlns.com/foaf/0.1/name
> 
> 2. Using an RDFa document:
> 
> This example uses @prefix to define the term 'name' without a colon:
> 
> <html vocab="http://xmlns.com/foaf/0.1/"
>   prefix="
>     foaf: http://xmlns.com/foaf/0.1/
>     dcterms: http://purl.org/dc/terms/
>     name http://xmlns.com/foaf/0.1/name
>   "
>> 
>   <head>
>     <title>My prefix mappings</title>
>   </head>
>   <body>
>     <p>This set of prefix mappings is for ...</p>
>   </body>
> </html>
> 
> This example uses @prefix to define the term 'name' with a colon, and
> consequenty requires us to remove any distinction between term and
> prefix mappings:
> 
> <html vocab="http://xmlns.com/foaf/0.1/"
>   prefix="
>     foaf: http://xmlns.com/foaf/0.1/
>     dcterms: http://purl.org/dc/terms/
>     name: http://xmlns.com/foaf/0.1/name
>   "
>> 
>   <head>
>     <title>My prefix mappings</title>
>   </head>
>   <body>
>     <p>This set of prefix mappings is for ...</p>
>   </body>
> </html>
> 
> This example uses a new attribute @term to define the term 'name', and
> then uses the same syntax as @prefix:
> 
> <html vocab="http://xmlns.com/foaf/0.1/"
>   prefix="
>     foaf: http://xmlns.com/foaf/0.1/
>     dcterms: http://purl.org/dc/terms/
>   "
>   term="name: http://xmlns.com/foaf/0.1/name"
>> 
>   <head>
>     <title>My prefix mappings</title>
>   </head>
>   <body>
>     <p>This set of prefix mappings is for ...</p>
>   </body>
> </html>
> 
> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> 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)
> 


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

Attachments

Received on Thursday, 21 October 2010 11:38:21 UTC