Re: ISSUE-1: Format of the profile document

Hi Manu,

On Sat, Mar 13, 2010 at 10:23 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 03/11/2010 02:46 PM, Mark Birbeck wrote:
>> I'm not sure why you're "ranting". :)
>
> It's the closest I get to exercise these days, which is why I await
> Spring with great anticipation. :)

He he...


> I'm also not too keen on the JSON solution for RDFa Profile documents as
> the primary document format. I think it creates more issues than it solves.

Sure...no problem. A format is a format.

I can go either way:

1. Keep it simple, and decide that we're only dealing with name/value pairs.

2. Use RDF to define a vocabulary, and use that vocabulary to create
tokens. (More on this at the end.)

If we go with (1) we don't have to use JSON, so as I keep saying,
let's put that aside.

If we go with (2), it makes sense to use RDFa, but that's obvious, so
let's put that aside.

So if you put aside JSON and RDFa, you are left with what we should be
talking about -- do we use RDF or simply name/value pairs to define
profiles?


>> With respect, I think you've missed the point here.
>
> I did miss a few points that came to light from the last e-mail you sent
> out:
>
> * There is the notion of replacing @xmlns: with something else, and I
> think you believe that is a part of this discussion. I think we can
> separate that into another discussion - it's a parallel issue.

No, I didn't say replacing, but anyway the sentiment I'm expressing is
nothing new.

We've said many times that if we create a new attribute, such as
@token or @vocab, then we should encourage the use of that attribute
as the primary mechanism -- that would amount to a kind of
'deprecation by convention' of @xmlns.

All I introduced into this discussion is that if we did do this, there
is nothing to force us to define @token/@vocab as being *exactly* the
same as @xmlns. I mentioned that in the context of some discussion
about backwards-compatibility; if we say that @token === @xmlns, then
any changes you make must be backwards-compatible. On the other hand,
if you say that @xmlns is not going to change, and instead that @token
is like @xmlns but with additional features, then you free yourself
from the backwards-compatibility question.

Of course we might not need this freedom -- I merely proposed a way to
get it if we need it.


> * We can re-use whatever mechanism that is used to define prefix
> mappings in the RDFa Profile documents. I disagree that this is the
> proper way forward - more below.

It was just an idea, and as with many ideas, it has pros and cons.
More on this below, though.


>> 1. We already define name/value pairs for prefix-mappings -- so I'm
>> not overburdening anyone. Hopefully that calms your "rant".
>
> My concern has more to do with the dual-use of the prefix/token/keyword
> mapping mechanism to define name/value pairs for prefix-mappings. I say
> dual-use because my understanding of your proposal is that we would use
> xmlns: to do both of the following:
>
> 1) Specify mappings in RDFa documents.
> 2) The RDFa Processor would import mappings from RDFa Profile documents
>   that use xmlns:.

I think you're alighting on a very small point here, when as I say,
the key thing is to first establish whether we should be using RDF at
all.

Anyway, more on this below.


> That may seem harmless at first glance but it has implications on what
> you can and can't do with RDFa Profile documents. Namely, what happens
> when an RDFa Profile document author doesn't want every xmlns:
> declaration to be imported into documents that utilize that RDFa Profile?

Indeed...I don't think anyone was trying to hide that scenario. :)

But I feel that we're trying to move towards a solution before we've
agreed on the basics; I'm trying to suggest that we need to be clear
on what is involved if we use RDF over name/value pairs.

You seem to be implying that we *must* use RDF, because if we use
name/value pairs there will be 'prefix leakage'...

...and I respond that this isn't true, because /one way/ out of that
would be to treat @token/@vocab differently to @xmlns...

...and you reply that this is undesirable, etc., etc.

But ultimately I'm not really making proposals 'as such', I'm just
trying to show that neither route is forced upon us, because there are
ways out. So we might as well just wrap up this name/value pair v. RDF
thing first. (Of which more below.)


> If I declare xmlns:owl and xmlns:foaf in my RDFa Profile document, but
> only want the foaf mapping to be available in the documents that import
> the profile, how do I accomplish this restriction with the name/value
> approach?

Maybe by saying that only @vocab/@token values get taken across?

Who knows?

Let's talk about that when we've agreed that at a fundamental
theoretical level, it is reasonable to use RDF to drive the parsing of
RDF.


>> 2. The core question is whether a profile should simply contain
>> further prefix-mappings (expressed in some way to be determined, such
>> as a bunch of @xmlns/@token statements in HTML, or some JSON, or
>> whetever), or whether a profile should contain a *vocabulary* that has
>> the magical properties that all items in the vocabulary also create
>> tokens for the parser to use.
>
> This is closer to what I thought we wanted as a group. This would allow
> RDF Vocabularies expressed in RDFa to be utilized as RDFa Profiles if
> the vocabulary author so desires.

I don't recall that being agreed at all, which is why this debate
feels to me to be running ahead of itself. Every time someone has
raised the possibility of using RDF to drive parsing, I've flagged up
the same issue. You'll see that I raised the same points come up in
the context of @rel="profile", for example. (In other words, I don't
think it has been agreed upon.)


> For example, if I were creating a Music Vocabulary and wanted beginner
> music bloggers to use it, I would say to use this markup:
>
> <div profile="http://example.org/music" typeof="Song">
>   <span property="title">Switch / Twitch</span>
>   <span property="artist">Fluke</span>
> </div>
>
> Perhaps there are a basic set of keywords that are supported, but if
> others wanted to use the more advanced features, they could do the
> following:
>
> <div xmlns:music="http://example.org/music#" typeof="music:Song">
>   <span property="music:title">Switch / Twitch</span> by
>   <span property="music:artist">Fluke</span> (length:
>   <span property="music:length" content="PT9M30S">9:30</span>)
> </div>

Absolutely.

It's a great illustration, and no-one is disagreeing with this use-case.


> I'd be very happy if vocabularies expressed in RDFa could be re-used as
> RDFa profiles.

As I said, I don't necessarily think that this is impossible, but I
think we have to nail down the conceptual issues. At the moment what
you have described is easily achieved using tokens and name/value
pairs. My suggestion would be that using vocabulary definitions to
drive these tokens is a *further* step, not a replacement step.

It's a bit like allowing an RDF graph to express @prefix values in N3;
you might add that as an enhancement, but you still need to support
@prefix, otherwise the bottom falls out of the whole thing.


> It would really help beginner RDFa authors to ignore
> mappings until they had a basic handle on RDFa.

Absolutely. In fact, for me this is all most people should ever need.


>> But the main thing I'm trying to say first is that we need to be clear
>> on what the issues actually are, before we get too stuck in to the
>> actual definition of this (the easy bit).
>
> Here is where I think I agree with you:
>
> 1) We should stop talking about prefixes/keywords/tokens and start
>   talking about them in some unified way - mappings? There is no
>   "list of prefix mappings" or "list of keyword mappings"... there
>   is just a "list of mappings".

Yes, definitely. :)

Maybe we should be bolder with our use of the term 'profile'.


> 2) We need something other than xmlns to declare those mappings since
>   xmlns is not semantically accurate.

Yes. And I would suggest that this new thing need not be
backwards-compatible if it helps us, since we'll retain @xmlns.


> Here is where I think we disagree:
>
> 3) We should re-use @xmlns/@token as the mechanism that we use to
>   declare mappings in RDFa Profile Documents. I'm strongly opposed
>   to doing that unless there is a simple way to solve the
>   non-determinism issue outlined above.

One way is to only import @token values. There won't be many scenarios
where profile authors need to have a mapping in the profile document
that doesn't leak, but if they really, really need that, they could
use @xmlns, and we could say that such values are *not* imported.

(This also gets us out of the hole that Ben flagged up, where the
presence or absence of a profile could change the meaning of a
document; we could say that it's only @token values that get
overridden by profiles, not @xmlns. Then we are 100%
backwards-compatible.)


> 4) JSON is an acceptable encoding mechanism if we agree to a
>   name/value based approach to RDFa Profile documents.

Fine.

I should say though, that I'm not seeing this with rose-tinted glasses
-- I know it has many horrible qualities. :)

But my experience of trying to import RDFa into my RDFa parser for use
in things like driving presentation (i.e., using Fresnel lenses) made
me eventually recast everything as JSON. Browser limitations are quite
important here, but of course that's an implementation question, and
maybe CORS solves it.


> Here is where I'm unsure on whether we agree or not:
>
> 5) The "list of mappings" can be extended through various mechanisms,
>   xmlns: is one, rdfa:mapping could be another.

We almost agree. :)

I believe that mappings are not RDF, and can never be -- and I think
this is a fundamental point that does need stressing.

However, as long as we keep our layers distinct, I don't have a
problem with the idea that a parser might 'magically' go from a term
that is in a vocabulary (expressed in some way to be decided, and
possibly even multiple ways) to a mapping.

Eventually I can see parsers that could load OWL ontologies, Tantek's
@profile documents, taxonomies, Dublin Core application profiles, and
so on, and create 'mappings' from the terms in those documents.

But my pedantic side says that these documents are not "defining
mappings" -- they are defining vocabularies that could be used to
generate a set of mappings. It may seem a small difference, but it's a
crucial distinction to maintain, for the correct construction of a
parser.

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)

Received on Sunday, 14 March 2010 12:09:05 UTC