Re: ISSUE-1: Format of the profile document

Hi Manu,

I'm not sure why you're "ranting". :)

With respect, I think you've missed the point here.

When I say RDF or non-RDF, I simply mean do we deal with name/value
pairs, or don't we.

For example, in RDF/XML and RDFa this is *not* RDF:

  <el xmlns:dct="http://purl.org/dc/terms/">
    ...
  </el>

All @xmlns does is to give you a name/value pair:

  'dct' => 'http://purl.org/dc/terms/'

Similarly, in SPARQL this is *not* RDF:

  @prefix dct: <http://purl.org/dc/terms/>

Once again, it simply gives you a name/value pair, which is then used
to process the RDF that follows.

Now of course, even someone who has been using RDF for a day could
work out how to express this in RDF. Create a bnode, give it an
rdf:type of 'prefix', give it a name and a value, and then you're
done:

  _:a a xyz:prefix .
  _:a xyz:name "dct" .
  _:a xyz:value <http://purl.org/dc/terms/> .

But the question is not *how* to do it -- that's easy peasy -- but whether to.

I'm not proposing some kind of "new syntax" that is going to
overburden web authors, because such a thing already exists. It exists
in SPARQL, RDF/XML, RDFa, and so on, and it's the 'syntax' for the
declaration of prefix-mappings.

(All I proposed was that if we expressed name/value pairs in JSON, we
got other benefits, but that's a side issue -- forget it for now.)

So what everyone needs to consider is whether using RDF to declare
prefixes for use in RDF makes sense. I.e., whether it holds water to
go from this:

  @prefix dct: <http://purl.org/dc/terms/>
  <> dct:creator "Manu" .

to this:

`Graph1:
  _:a a xyz:prefix .
  _:a xyz:name "dct" .
  _:a xyz:value <http://purl.org/dc/terms/> .

Graph2:
  <> dct:creator "Manu" .

So to recap:

1. We already define name/value pairs for prefix-mappings -- so I'm
not overburdening anyone. Hopefully that calms your "rant".

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.

The 'profile as vocabulary' technique is not completely unworkable. :)

If we go that way then I think we should be looking at Dublin Core
Profiles, my argot work, and other related initiatives to see what
commonality can be achieved.

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

(Now my rant is over. :))

Regards,

Mark

On Thu, Mar 11, 2010 at 6:59 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 03/11/10 13:01, Mark Birbeck wrote:
>> Sounds like a great meeting, sorry I missed it.
>
> We missed having you there as well. :)
>
>> So RDF or not RDF is the first question to resolve --
>> CORS, JSONP, and so on, come next. :)
>
> (co-chair hat off - opinionated rant to follow) :)
>
> I would be very surprised if we settled on anything other than RDF. We
> have these mechanisms (RDF and RDFa) that were designed to express
> exactly what we need (a vocabulary document that is both machine and
> human readable) in a fairly succinct manner that re-uses the same
> code-path that we've designed and tested many times over, and we're
> discussing another slightly more succinct mechanism for marking up RDFa
> profiles.
>
> I don't think the question is whether or not we are capable of inventing
> a new, more succinct mechanism for markup of RDFa profiles. We are most
> certainly capable and could do so if necessary.
>
> The big issue with going with anything other than RDF and RDFa is the
> added complexity to the RDFa Processors and the added burden on authors
> to understand yet one more markup mechanism for utilizing RDFa.
>
> If we pick something that is not RDF and RDFa, we are adding unnecessary
> complexity and authoring burden to a system that is already considered
> on the edge of being painfully complex for RDFa processor developers and
> difficult to understand for new semantic web authors.
>
> Please, let us not pile on more that web authors have to learn to use
> RDFa. I just don't see how creating a new RDFa profile markup mechanism
> moves the web forward.
>
> -- 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 Thursday, 11 March 2010 19:47:17 UTC