Re: Complexity of RDFa

Hi Constantine,

I don't think you're wrong...I just don't think that's RDFa.

RDFa comes into its own when you want the metadata to be aligned with
the inline data -- useful in search and browser enhancements.

But if you're not bothered about the alignment, you might as well put
the data in another document.

Of course, as you rightly say, that then gives you another document to
maintain, so putting it inline would be advantageous. But maybe all we
need is a 'convention' rather than some new standard. For example,
<script> is often used to hold data as well as code, so why not use
that for your use-case:

  <script type="application/rdf-n3">
    <>  a cw:LawFragment;
      cw:infoClass cw:LegislationRegulation;
      ltr:referenceInformation _:b0 .
        _:b0 a ltr:ReferenceInformation;
         officialPublication <http://some.uri>;
         ltr:applicablePeriod _:b1 .
           _b:1 a ltr:ApplicablePeriod ;
             cw:startDate "2009-04-24T00:00:00+01:00"^^xsd:dateTime ;
             cw:endDate "2010-04-24T00:00:00+01:00"^^xsd:dateTime .
  </script>

I've Googled around to see if people already use this technique, but
although I can't find anything, I'd be really surprised if someone,
somewhere, hadn't tried it.

(It's the kind of thing Creative Commons might have looked at...any
comments, Ben?)

Regards,

Mark

On Thu, Apr 1, 2010 at 9:46 AM, Hondros, Constantine
<Constantine.Hondros@wolterskluwer.com> wrote:
> Hi Bob,
> I think what you say is entirely valid for marking up database-generated
> product listings, as in Ebay, Amazon, Best Buy. Here you probably just want
> to add a number of strongly-typed values using a well-known RDF vocabulary.
>
> In the world of publishing, however, our metadata may be based on a complex
> domain ontology with a class hierarchy. As an example, this is (just a
> fragment of) the typical metadata that might be associated with an article
> of legislation.
>
> <>  a cw:LawFragment;
>     cw:infoClass cw:LegislationRegulation;
>     ltr:referenceInformation _:b0 .
>      _:b0 a ltr:ReferenceInformation;
>         officialPublication <http://some.uri>;
>         ltr:applicablePeriod _:b1 .
>          _b:1 a ltr:ApplicablePeriod ;
>             cw:startDate "2009-04-24T00:00:00+01:00"^^xsd:dateTime ;
>             cw:endDate "2010-04-24T00:00:00+01:00"^^xsd:dateTime .
> I see real complexity trying to represent this inline with RDFa. For
> example, the date literals will certainly be in the body of the document,
> so should I create a typed blank node in situ, and reference it from the
> more general metadata in the top of the document?
>
> Probably the obvious solution is to publish and maintain the RDF info
> separately ... but that carries a management overhead of its own. Again, I
> feel it would be nice to have a permissive HTML construct in the head of a
> document that can accept RDF metadata of arbitrary complexity.
>
> ________________________________
> From: Bob DuCharme [mailto:bob@snee.com]
> Sent: 31 March 2010 17:28
> To: Hondros, Constantine
> Cc: public-rdfa@w3.org
> Subject: Re: Complexity of RDFa
>
> Hi Constantine,
>
> I've always felt that the W3C RDFa examples that show markup embedded in
> prose discussions of upcoming picnics were going to give the wrong
> impression about how easy it would be to automate the insertion of this
> markup. A lot of the ASP, PHP, and JSP programmers are reading data from
> relational databases and generating HTML tables on the fly (e.g. airline and
> theater schedules) and adding extra attributes and/or wrapper elements
> within the rows of those tables to show which td element has the start time
> and which has the price is very little trouble.
>
> I suppose I understand the attitude of not wanting to clutter up their
> output with new stuff for this new application, and wanting to put it into a
> header instead, but like the class attribute that their code would have
> added to provide hooks to a CSS stylesheet, RDFa adds semantics that can
> provide hooks to all kinds of applications, so I think it's worth it.
>
> Bob
>
> Hondros, Constantine wrote:
>
> Yes, the syntax has at times made me blink hard.
>
> Actually, I have a different issue with RDFa. It seems to have been
> developed from the point of view of people manually typing up html pages.
> The vast majority of HTML these days is spat out after some sort of
> server-based fusion of template and database query. ASP, PHP, and
> JSP programmers are pragmatic types who I suspect would like to be able
> to dump out a pages RDF content somewhere near the top of the file rather
> than modify directives in their code that produce XHTML elements.
>
> Agreed, of course, the original idea is to annotate the content within the
> page itself, and if you RDF-dump somewhere at the top of your page you will
> almost certainly end up duplicating some literal values. However, I think it
> might lower the benchmark for a lot of database publishers to start
> inserting RDF into their pages.
>
> Or to put it another way ... database publishers must go to lots of effort
> to insert RDFa tags at the precise location in the page where any literal
> values are expressed, only for an RDFa-reading application to parse it right
> out again. Since all the info is coming out of a database anyway, why not
> let the page developer squirt the RDF somewhere in the file at their
> convenience?
> ________________________________
> From: public-rdfa-request@w3.org [mailto:public-rdfa-request@w3.org] On
> Behalf Of Rob Vesse
> Sent: 29 March 2010 14:19
> To: public-rdfa@w3.org
> Subject: Complexity of RDFa
>
> Hi all
>
> So following up on a discussion I had with Manu via Twitter I just want to
> raise the following couple of points about my opinions on RDFa.
>
> My main issue with RDFa is that like RDF/XML it lets you state the same
> thing in a lot of different ways.  While this may be somewhat necessary when
> the aim is to provide a format that can be embedded inside XHTML and HTML
> which themselves have lots of different ways of expressing the same thing I
> think it makes it difficult for developers and end users to decide how best
> to do something.  Essentially I feel it’s over complex in some ways - for
> example there are about 7 different ways that the subject of a triple can be
> set and the order & priority of these changes if there is an @rev or @rel on
> the element.
>
> In some respects from a developer standpoint (in terms of parsing) this
> complexity is irrelevant, the rules are very clear and you can write a
> parser relatively quickly that can extract the RDFa from HTML/XHTML.  But
> from a developer standpoint in terms of embedding your RDF as RDFa inside
> your markup it’s a lot trickier to decide how best to do this because of the
> many options on offer.
>
> The other issue I raised is that while the RDF model is intended to encode
> machine-readable data I’d much prefer to have a concrete syntax that is also
> human readable e.g. Turtle.  While I can now after a year or so of staring
> at it far too often read RDF/XML reasonably well I have yet to stare at
> enough RDFa snippets to be able to do this and my feeling is that this is
> far harder to do because you typically have all the extra non-RDFa stuff
> associated with normal HTML/XHTML markup.  Manu’s response to this is that
> any non-trivial RDFa snippet typically does require you to shove it through
> a parser to see what you’ve actually encoded which I fully appreciate and he
> made the point that we use already web browsers to double-check JS, HTML,
> CSS etc.  Yet if I write any JS, HTML, CSS etc I can easily see the intended
> structure and function of the markup/code even if I have to run it through
> my web browser to show up any typos, bugs, glitches etc whereas with RDFa I
> don’t feel I can do this in quite the same way.
>
> Perhaps this may just be a case of not having worked with RDFa for long
> enough to feel truly comfortable with it – what do other people in the
> community think?
>
> Rob Vesse
>
> PhD Student
>
> IAM Group
>
> Bay 20, Room 4027, Building 32
>
> Electronics & Computer Science
>
> University of Southampton
>
> SO17 1BJ
>
> ________________________________
> This email and any attachments may contain confidential or privileged
> information
> and is intended for the addressee only. If you are not the intended
> recipient, please
> immediately notify us by email or telephone and delete the original email
> and attachments
> without using, disseminating or reproducing its contents to anyone other
> than the intended
> recipient. Wolters Kluwer shall not be liable for the incorrect or
> incomplete transmission of
> of this email or any attachments, nor for unauthorized use by its employees.
>
> Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The
> Netherlands, and is registered
> with the Trade Registry of the Dutch Chamber of Commerce under number
> 33202517.
>

Received on Thursday, 1 April 2010 09:07:40 UTC