Re: Profiles in RDFa 1.1

Hi Mark,

Thanks for both proposals for addressing the format of RDFa Profiles.
Some of those on this list may not be aware of another mechanism that
Mark and I are working on to get Linked Data expression working for
JSON, called JSON-LD:

http://json-ld.org/

JSON-LD is based on work that Mark did on RDFj and on work that Ian
Davis did on RDF/JSON. Some of the proposals that Mark makes below
resonate with me because the thinking is in-line with the direction of
JSON-LD, but probably for different reasons than the reasons why they
resonate with him. However, there are a few more issues that both
proposals create that we do not currently have... more below.

On 10/20/2010 06:56 PM, Mark Birbeck wrote:
> PROPOSAL 1: USING @PREFIX FORMAT
> 
> We already have a syntax for defining prefix mappings:
> 
>   <div prefix="
>       foaf: http://xmlns.com/foaf/0.1/
>       dcterms: http://purl.org/dc/terms/
>     ">...</div>
> 
> We could easily use this for our external file format:
> 
>   foaf: http://xmlns.com/foaf/0.1/
>   dcterms: http://purl.org/dc/terms/
> 
> Advantages:
> * doesn't use RDF;

I think that this is a drawback, not an advantage - more below...

> * consistent with the way that scripts and stylesheets work;

Yes, definitely.

> * doesn't require a full RDFa parser -- only requires the part that processes
>   @prefix;

I understand your argumentation that we have conceptual layering issues
if we require an RDFa processor to understand an RDFa document. However,
I don't think that it has a large impact on one's understanding of how
to use RDFa correctly. In other words, we're not chartered to create
something that is theoretically pure for the sake of theoretical purity.
I'm not saying that you're asserting that either, but I fail to see the
technical issue that this creates. If we don't require an RDFa parser,
we require another type of parser to understand the external file - we
still need a parser to understand the external document. I don't think
it's as big of a deal as you seem to think it is, even after having had
several weeks to digest your point of view.

> * easy to take mappings from a document and create a profile with them,
>   without having to know RDF.

If this is really an issue for people, it is easily remedied by
providing an RDFa Profile document generator. However, I don't think
that it is going to be an issue for the majority of RDFa Profile authors
if we just provide a simple pattern for people to follow.

> Disadvantages:
> 
> * no commenting mechanism, so not self-describing.
> (Of course, a commenting mechanism could easily be added!)

Yes, but we'd have to add a commenting mechanism, at which point, we're
creating another markup language. I'm not saying it can't be done, just
asking how many markup languages we need to involve in this process -
XML, HTML, RDFa, and now RDFaProfileFlatFile?

I'd add the following to the list of disadvantages:

> * doesn't use RDF (or other extensible mechanism);

I don't know if you were present when we discussed this or not, but
another reason that RDF entered the picture is because both Shane and I
wanted a way to allow people to extend the RDFa processor behavior in a
way that was extensible and free-form. Here's an example:

Facebook decides that they want to support type coercion for their Open
Graph Protocol but still want to stay true to the RDFa specifications.
They may choose to do this via RDFa Profile documents by expressing the
following triples in the RDFa Profile documents:

_:bnode1 rdfa:uri "http://ogp.me/ns#url" .
_:bnode1 ogp:coerce xsd:anyURI .

These triples basically state that when someone does this in their
HTML+RDFa document, while using the OGP RDFa Profile:

<meta property="ogp:url" content="http://example.org/page" />

that the following triple MUST be generated in the default graph:

<> ogp:url "http://example.org/page" .

and the following triple MUST be generated in the Facebook RDFa
processor graph:

<> ogp:url <http://example.org/page> .

This approach allows Facebook to extend their processor behavior and
innovate on top of RDFa via their profile documents. They may learn from
their implementations and perhaps bring a standardization proposal to
W3C for type coercion (if it becomes a popular extension for RDFa
Processors).

I know this made Ivan nervous the last time we mentioned this, but we
leave the door open for this kind of innovation if we take the RDF route.

If we take the flat text file approach that you're proposing above, we
shut the door on that sort of innovation and I think it would be a shame
to do so.

> PROPOSAL 2: PARSE @XMLNS/@PREFIX/@VOCAB ON EXTERNAL DOCUMENT
> 
> An additional/alternative proposal would be to use RDFa in the
> external document, but only take account of the @xmlns, @prefix and
> @vocab attributes.
> 
> Advantages:
> 
> * easy to take mappings from a document and create a profile with them,
>   without having to know RDF;

I'm assuming that you intend the @vocab, @prefix, and @term statements
to be specified only on the <html> element? So, if somebody puts these
statements on the <body> or a random <p> tag it doesn't work? We're also
breaking the whole concept of scoping aren't we? Until now <base> was
the only really weird thing in RDFa re: scoping, but now we're saying
that scoping works differently in RDFa Profile documents. One more
strange RDFa-ism to remember - it's not consistent at all.

> * self-describing, in that the HTML document can contain a description of the
>   profile, links to resources, etc.
> 
> Disadvantages:
> 
> * there is currently no way to define a term in a document. However, I believe
>   this is an omission in RDFa generally, so shouldn't be regarded as a
>   limitation here.

True, but in order to fix this disadvantage, we MUST add a @term
attribute to RDFa. With the current approach, we don't need to keep
tacking on new attributes every time we want to support a new feature.

I do agree with you that it would have been nice to formalize prefixes
and terms into something like @token. I thought that we were very close
to just doing something like this:

prefix="foaf: http://xmlns.com/foaf/0.1/
        name: http://xmlns.com/foaf/0.1/name"

but, that didn't happen - and it didn't happen because of the current
design for RDFa Profiles. In fact, I think it proves that the RDF model
for extending processing behavior is not only solid, but more powerful
than most people realize. It's not an omission as you claim - it's by
design.

We did roughly explore both of these avenues during the many
telecons/on-list/off-list/Skype/Twitter discussions that have gone on
for the many months that this group has been active, so I do think that
these ideas were given due consideration before. Of course, you may feel
differently.

While I do think that both approaches that you've described are
technically sound, I don't think that they're better than what we
currently have.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Saving Journalism - The PaySwarm Developer API
http://digitalbazaar.com/2010/09/12/payswarm-api/

Received on Thursday, 21 October 2010 01:34:27 UTC