Re: Small @profile question

On 10 September 2010 02:55, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:

> On Sep 9, 2010, at 5:32 PM, Melvin Carvalho wrote:
>
> On 9 September 2010 22:39, Nathan <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.
>
>
Agree this is invaluable.


>
>    - We don't typically define all style information, it's included using
>    a <link rel="stylesheet"> tag.
>
>
Again, css in a separate document seems a logical no brainer.


>
>    - Many documents are not complete in and of them selves, but reference
>    each other using <link rel="next"> or similar.
>
> Again, see the logic.  Linking documents is what the web of data is all
about.


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

Re: caching I'm not seeing a huge gain here.  We dont, for example, have a
separate name space document for RDF/XML, N3, Turtle etc. AFAIK.  And surely
the header element will very often be in a separate html file anyway?

In terms of losing @xmlns from the document I think that is a major
simplification as the syntax is ugly and hard to remember with the : in
there.  I would imagine this is off putting to many developers, hence
including a generic @profile tag would be much easier.  Developers are used
to name value pairs.  Did anyone consider simplifying this syntax?

Is there a concern that this could lead to becoming an unbalancing factor in
terms of 'ontology wars'.  AIUI RDF is a bottom up model where anyone is
free to create an ontology, and the better ones will rise in usage
organically.  Will @profile move us towards a world with a dozen or so
'blessed' profiles which can be skewed in favor of certain ontologies over
others, much like you have default CA's in your browser.

I'm not saying I disagree with @profile, as I stated before, I've only been
following this list from a distance, and I would like to examine the spec in
more detail before making a considered comment.  So please disregard the
comments above if they have been covered before, or somewhat basic.  But if
anyone has an opinion on this, would love to hear!


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