Re: Small @profile question

On Sep 9, 2010, at 5:32 PM, Melvin Carvalho wrote:
On 9 September 2010 22:39, Nathan <nathan@webr3.org<mailto:nathan@webr3.org>> wrote:
Mark Birbeck wrote:
...actually re-reading your email I see a third possibility which is
probably what you mean. If A is processed without processing P, then
if every CURIE or term in A relied on a mapping in P then no graph
would be generated.

If that's what you mean, then yes, that is possible.

Yup, that's what I meant - thanks for clarifying Mark :)

Rather than diving in to all the possible issues/cons I see with this, as it's probably very well trodden ground, all I will say is:

1: It was my (possibly naive) understanding that one of the main considerations when writing a spec or protocol, is to constrain the specification such that possible points of failure and unexpected behaviour are reduced to an absolute minimum (@profile appears to introduce multiple counts of both, which previously did not exist.)

2: I really do think @profile could simplify the task of adding semantic markup, I just feel like it's a nice feature for an RDFa IDE that inserts all your prefixes for you, rather than part of the spec (let along core).

3: When RDFa 1.1 hits the main stream I'd fully expect to see @profile being the cause of every second RDFa related question/problem on sites like stack overflow. I can already see the defacto responses and I'm sure you can too: "you missed out a profile", "xyz prefix isn't in your profile", "your profile's on a server that's went down", "rdfa:uri should be a string not a <uri>", "somebody has edited the profile document without you knowing" and so forth.

There's certainly a lot of precedent for using an external resource to define things required to properly interpret HTML, or other content.


 *   We don't define all JavaScript need to present a document, we include it using a <script> tag.
 *   We don't typically define all style information, it's included using a <link rel="stylesheet"> tag.
 *   Many documents are not complete in and of them selves, but reference each other using <link rel="next"> or similar.

Looking at RDFa documents as a publication platform, I definitely see a need to allow common definitions to be defined a separate file, for much the same reason that I wouldn't want to repeat JavaScript and CSS elements in the body of each HTML file. That's not to say that some people won't want to define term and prefix mappings within the body of a document, but for consistency among a set of similar documents, the principle of "Don't Repeat Yourself" seems pretty important.

Thanks for raising.  I kind of had this feeling too ... was not really familiar enough with RDFa 1.1 to voice it.

Hopefully I'll get to know the spec better as it moves towards completion ...


Apologies, but for my own peace of mind I had to at least say something.


There have been discussions at times about adding triples to the
triple-store even if they have unmatched prefixes, allowing them to be
'fixed' at a later time; but we've never got very far with that.

I can see why that may be needed when @profile is in RDFa, yet.. ouch.

Best,

Nathan



On Thu, Sep 9, 2010 at 7:48 PM, Nathan <nathan@webr3.org<mailto:nathan@webr3.org>> wrote:
Hi,

I just wanted to check my understanding was correct quickly.

@profile allows me to author an RDFa document where the prefixes are stored
in an external document pointed to by @profile.

As in, author an RDFa document which when considered by itself, contains no
RDF graph.

is that correct?

Best,

Nathan


Gregg