Re: ISSUE-1: Format of the profile document

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

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.

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

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

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?

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?

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

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>

I'd be very happy if vocabularies expressed in RDFa could be re-used as
RDFa profiles. It would really help beginner RDFa authors to ignore
mappings until they had a basic handle on RDFa.

> 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".
2) We need something other than xmlns to declare those mappings since
   xmlns is not semantically accurate.

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.
4) JSON is an acceptable encoding mechanism if we agree to a
   name/value based approach to RDFa Profile documents.

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.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Saturday, 13 March 2010 22:24:05 UTC