Re: best practice RDF in HTML

[Mark Birbeck]

Hi Sebastian,

It's not clear to me whether you are saying that you don't want to use
RDFa because:

* you don't like it, or;

* you think that it needs to have some user-oriented manifestation.

There is no requirement that the RDFa in a document is displayed to
the user in any way, or that the triples somehow 'double-up'. This
means that your example could also be marked up like this:

  http://www.recshop.fake/cd#";
    about="http://www.recshop.fake/cd/Empire_Burlesque";
  >
    
    http://dbpedia.org/resource/Empire_Burlesque";>
  

Regards,

Mark


On Tue, Jun 12, 2012 at 3:02 PM, Sebastian Hellmann
 wrote:
> Dear list,
> What are the best practice to include a set of RDF triples in HTML.
> *Please note*: I am not looking for the RDFa way to include triples. I just
> want to add a set of triples somewhere in an HTML document. They are not
> supposed to show up like "Wikinomics", "Don Tapscott" in  the following
> example:
>
> http://purl.org/dc/elements/1.1/";
>  about="http://www.example.com/books/wikinomics";>
>  Wikinomics
>  Don Tapscott
>  2006-10-01
> 
>
> I don't want to use the strings in the HTML document as objects in the
> triples. My use case is that I just have a large set of triples, e.g. 1000
> that I want to include as a bulk somewhere and ship along with the html.
> Which way is the best? Do the examples below work?
> All the best,
> Sebastian
>
> ***
> Include in head
> **
> 
> 
> 
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
> xmlns:cd="http://www.recshop.fake/cd#";>
>
>  rdf:about="http://www.recshop.fake/cd/Empire Burlesque">
> Bob Dylan
> http://dbpedia.org/resource/Empire_Burlesque"; >
> 
> 
> 
> 
> 
> 
> 
> **
> attach after html
> *
> 
> 
> 
> 
> 
> 
>  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
> xmlns:cd="http://www.recshop.fake/cd#";>
>
>  rdf:about="http://www.recshop.fake/cd/Empire Burlesque">
> Bob Dylan
> http://dbpedia.org/resource/Empire_Burlesque"; >
> 
> 
>
>
> --
> Dipl. Inf. Sebastian Hellmann
> Department of Computer Science, University of Leipzig
> Projects: http://nlp2rdf.org , http://dbpedia.org
> Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
> Research Group: http://aksw.org
>
>

Re: Creating JSON from RDF

[Mark Birbeck]

An excellent summary of the state of play so far, Dave...count me in. :)


On Thu, Dec 17, 2009 at 1:48 PM, Dave Reynolds
 wrote:
> Dave Reynolds wrote:
>
>> Jeni Tennison wrote:
>
>>> I don't know where the best place is to work on this: I guess at some
>>> point it would be good to set up a Wiki page or something that we could use
>>> as a hub for discussion?
>>
>> I'd suggest setting up a Google Code area and making anyone who is
>> interested a committer. That gives us a Wiki but also hosting for associated
>> code for generating/navigating the format. I'd be happy to set one up.
>
> Now done. We've opened a Google Code area "linked-data-api" and summarized
> both the aims/assumptions [1] and the various design issues and suggestions
> that have come out of the list discussions so far [2].
>
> The wiki is public access for reading and commenting.
> Anyone who is interested in joining in with working on this please ping
> either Jeni or myself and we'll add you as a committer.
>
> Cheers,
> Dave
>
> [1] http://code.google.com/p/linked-data-api/wiki/AssumptionsAndGoals
> [2] http://code.google.com/p/linked-data-api/wiki/DesignQuestions
>

Re: Creating JSON from RDF

[Mark Birbeck]

Hi Richard,

> Despite the "Bah, Humbug!" tone of my previous mail, I am actually in favour
> too.  I just want to tease out the extent to which we would be giving
> developers what they say they want, rather than what they could actually
> use.
>
> The value of JSON is surely that JSON support is widespread across a wide
> range of programming environments[1], rather than that JSON is a "simple"
> format.  Would the alternative formats being discussed offer as much, in
> terms of their practical implementation for a wide range of languages?

I'm speaking for myself here, but going on her first email, I'm pretty
sure that Jeni is taking the same approach.

The goal is to make it easy for web programmers to get RDF data
directly into their applications. So although it's true that JSON is a
general-purpose format, our interest here is more specific, in that it
easy to get JSON data directly into web applications.

For those who don't do a lot of JavaScript programming, I should point
out a subtlety here that might be being missed; although modern web
apps make extensive use of XMLHttpRequest objects to retrieve data, in
ordinary circumstances it is not possible to use XHR to get data from
a different domain to the one hosting HTML document.

However, HTML /does/ allow the 

Re: Creating JSON from RDF

[Mark Birbeck]

Hi Richard,

Isn't:

> Give 'em RDF and tell them to develop better toolsets ...

exactly the approach that the RDF community has been pursuing for a
decade or two, with less than impressive results?

;)

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birb...@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)

Re: Creating JSON from RDF

[Mark Birbeck]

t;,
>    "maker": {
>      "$": "http://example.org/anna";,
>      "name": "Anna Wilder",
>      "homepage": "http://example.org/about";
>    }
>  }
>
> or:
>
>  {
>    "$": "http://example.org/anna";,
>    "name": "Anna Wilder",
>    "homepage": {
>      "$": "http://example.org/about";,
>      "title": "Anna's Homepage",
>      "maker": "http://example.org/anna";
>    }
>  }
>
> The one that's required could be indicated through the configuration, for
> example:
>
>  <> a api:API ;
>    api:mapping [
>      api:property foaf:maker ;
>      api:name "maker" ;
>      api:embed true ;
>    ] .

I realise that the two serialisations of RDFj would not be the same,
but I'm not seeing what difference that would make.

Are you thinking that someone might write some code that relies on the
structure of the object, and then gets thrown by a change in
structure?

I guess that's true, but in my work on RDFj, I had come to the
conclusion that people would write processors that deal with little
blocks of the data, and then call those as and when. So in your
example, if we wrote a processor that handled the object attached to
the predicate 'maker' and another processor for the predicate
'homepage', then it shouldn't really matter in which order the data
appeared, the correct processors would just be called.

But also -- and this may be a key difference in our view on a possible
architecture -- I place all RDFj /received/ into a triple store,
alongside any other triples, including RDFa-generated ones, and then
the author retrieves RDFj from this triple store, and consequently can
structure the data in whatever way they prefer.


> The final thought that I had for representing RDF graphs as JSON was about
> suppressing properties. Basically I'm thinking that this configuration
> should work on any graph, most likely one generated from a DESCRIBE query.
> That being the case, it's likely that there will be properties that repeat
> information (because, for example, they are a super-property of another
> property). It will make a cleaner JSON API if those repeated properties
> aren't included. So something like:
>
>  <> a api:API ;
>    api:mapping [
>      api:property admingeo:contains ;
>      api:ignore true ;
>    ] .

I think we need to be thinking about how to get closer to SPARQL here,
though. (Actually this point is the same for a number of the other
circumstances.)

My fear here is that we're either duplicating the functionality that
can be provided within a SPARQL query, or we're adding a layer above
it, when actually the information should be expressed at the query
layer.

I'm not suggesting that JavaScript authors should have to get involved
with SPARQL. But if we imagine SPARQL recast for JavaScript, then I
think it's there that the kinds of things you want should be
described, and not in the API.

Perhaps we should look at the query side, and then move some of your
constraints into that?


> # SPARQL Results #
>
> I'm inclined to think that creating JSON representations of SPARQL results
> that are acceptable to normal developers is less important than creating
> JSON representations of RDF graphs, for two reasons:
>
>  1. SPARQL naturally gives short, usable, names to the properties in JSON
> objects
>  2. You have to be using SPARQL to create them anyway, and if you're doing
> that then you can probably grok the extra complexity of having values that
> are objects

I think the two things are inseparable, but that's probably because,
as I say, I put all data into a JavaScript triple store, and then
query it with a SPARQL-ish JavaScript syntax.

Currently I get back simple JSON objects that have properties that are
the name of the values used in the query, but my plan is to converge
the query results with my RDFj work, so that it's RDFj in, and RDFj
out.

I've said this before, I know, but what's great about this technique
is that the query engine becomes a 'JSON-object creator', and I think
this is a very powerful programming paradigm.


> Nevertheless, there are two things that could be done to simplify the SPARQL
> results format for normal developers.
>
> One would be to just return an array of the results, rather than an object
> that contains a results property that contains an object with a bindings
> property that contains an array of the results. People who want metadata can
> always request the standard SPARQL results JSON format.
>
> The second would be to always return simple values rather than objects. For

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Pat,

> I have checked with my system admin, and they tell me, Yes that is correct.
> You cannot access your .htaccess file. You cannot modify it or paste
> anything into it. Only we have access to it. No, we will not change this
> policy for you, no matter how important you think you are. Although they do
> not say it openly, the implicit message is, we don't give a damn what the
> W3C thinks you ought to be able to do on our website.

I agree that this seems to be getting like Groundhog Day. :)

The original point of this thread seemed to me to be saying that if
.htaccess is the key to the semantic web, then it's never going to
happen.

I.e., ".htaccess is a major bottleneck".

The initial discussion around that theme was then followed by all
sorts of discussions about how people could create scripts that would
choose between different files, and deliver the correct one to the
user. But the fact remained -- as you rightly point out here -- that
you still need to modify .htaccess.


> Now, has anyone got any OTHER ideas?  An idea that does not involve changing
> any actual code, and so can be done using a text editor on an HTML text
> file, would be a very good option.

:)

Did I mention RDFa?

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Martin,

> Beyond that, RDFa can create code that is very
> hard to maintain. In fact, I know that a large software company
> dismissed the use of RDFa in their products because of the unmanageable
> mix of conceptual and presentation layer.

Now I'm going to sound like I don't believe there are any problems with RDFa.

But... :)

The issue here is not that RDFa forces a mix of conceptual and
presentation layers -- it would be more correct to say that RDFa
_allows_ for a mix of conceptual and presentation layers. But there is
nothing to force that mixing, and RDFa can also be used for different
points along the spectrum.

For example, I could create an RDF schema or OWL ontology using RDFa,
which would be much the same, in terms of verbosity, as an RDF/XML
version. It might never be used in web browser, and so occupy a
position on the spectrum well away from the presentation end.

In this scenario the RDFa document is simply playing the role of an
equivalent RDF/XML document, with the only difference being that it
can be deployed using HTML infrastructure.

Another scenario would be to have one HTML+RDFa document for humans,
and another for machines, in just the same way that most deployment
scenarios currently involve two different documents (one HTML and one
RDF/XML).

The main thing is that you now have a choice, and the key point I'm
trying to make is that if the company you were dealing with mixes up
the conceptual and presentation layers, that's nothing to do with
RDFa, since it's perfectly possible to separate them as much or as
little as you like.

In fact it's a little like blaming HTML's @style attribute for causing
you to 'mix up presentation and content', when HTML actually has a
very powerful mechanism for keeping them apart, in CSS stylesheets.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Toby,

Yes...of course...you are right. :)

I would say too, that reification is even more long-winded than the
example you have given! You don't have the actual statement "the sky
is blue" in your mark-up, so you need even more RDFa. (You only have
the statement "Mark says 'the sky is blue'".)

But either way, you are right that the whole thing can be spelt out
longhand (as can lists).

The only reason I mentioned it was because for a long time in RDFa we
had a much simpler construct based on occurrences of *nested* 
and  properties. However, some browsers thought they were doing
us a favour by moving the  and  elements out of the 
and into the , which meant it was not possible to implement this
feature in JavaScript. (Obviously server-side RDFa parsers would have
had no problem with it.)

As for lists, the obvious shorthand would be , , and , but
it was not obvious what triples should be generated, so we left it.
I.e., your example uses the first/next/nil technique for collections,
but of course there is also the rdf:_1 technique for a list. It wasn't
immediately clear which would be the more useful -- or conformant --
one to generate.

Regards,

Mark

On Mon, Jun 29, 2009 at 2:05 PM, Toby Inkster wrote:
> On Mon, 2009-06-29 at 13:30 +0100, Mark Birbeck wrote:
>> If we go back a step, RDFa was carefully designed so that it could
>> carry any combination of the RDF concepts in an HTML document. In the
>> end we dropped reification and lists, because it didn't seem that the
>> RDF community itself was clear on the future of those, but they are
>> both easily added back if the issues were to be resolved.
>
> RDF reification and lists do *work* in RDFa, they're just a bit of a
> pain to mark up.
>
> e.g. here's a reification:
>
> http://purl.org/dc/elements/1.1/";
>    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>    xmlns:db="http://dbpedia.org/resource/";
>    typeof="rdf:Statement">
>  Mark Birkbeck says that
>  the sky
>  http://dbpedia.org/property/color";
>      >is
>   blue.
> 
>
> And an example of a list can be found here:
>
> http://ontologi.es/rail/routes/gb/VTB1.xhtml
>
> --
> Toby A Inkster
> <mailto:m...@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
>



-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Tom,

On Sun, Jun 28, 2009 at 11:46 PM, Tom Heath wrote:
> Martin,
>
> 2009/6/27 Martin Hepp (UniBW) :
>> So if this "hidden div / span" approach is not feasible, we got a problem.
>>
>> The reason is that, as beautiful the idea is of using RDFa to make a) the
>> human-readable presentation and b) the machine-readable meta-data link to
>> the same literals, the problematic is it in reality once the structure of a)
>> and b) are very different.
>>
>> For very simple property-value pairs, embedding RDFa markup is no problem.
>> But if you have a bit more complexity at the conceptual level and in
>> particular if there are significant differences to the structure of the
>> presentation (e.g. in terms of granularity, ordering of elements, etc.), it
>> gets very, very messy and hard to maintain.
>
> Amen. Thank you for writing this. I completely agree. RDFa has some
> great use cases but (like any technology) has its limitations. Let's
> not oversell it.

Mmm...you put me in a difficult position here. :)

If I leap to RDFa's defence then it looks like I think it solves all
the world's problems.

But if I remain silent, then it looks like the problem being raised is
some kind of fundamental flaw.

Ah well, let's dive in...

First I should say that I'd be the first to agree that RDFa has
limitations. But the issue here is that I don't think the problem
raised by Martin can be classed as a limitation in the way you're
implying, Tom.

If we go back a step, RDFa was carefully designed so that it could
carry any combination of the RDF concepts in an HTML document. In the
end we dropped reification and lists, because it didn't seem that the
RDF community itself was clear on the future of those, but they are
both easily added back if the issues were to be resolved.

In short, it is possible to use HTML+RDFa to create complete RDF
documents, such as RDF Schemas, OWL ontologies, and so on, and the
resulting documents would be no more complex than their equivalent
RDF/XML or N3 versions, with the benefit that they can be delivered
using any of the many HTML publishing techniques currently available.

But most of the discussion around RDFa relates to its other use, where
it's possible to use it to 'sprinkle' metadata into HTML documents
that are primarily aimed at human readers. By being alongside the
human-readable output, it makes the metadata easier to maintain. And
in addition it gives the user agent the opportunity to enhance the
view of the data, by making use of the 'local' metadata.

However, the point that Martin was getting at, is that sometimes there
is just way more data in the 'RDF view' than in the 'human view', and
that makes it very difficult to make the two align.

I don't think that this is a flaw in RDFa itself, and I'm not
convinced that there is an easy solution in the form of another
technology that would solve this. Martin's solution seems a reasonable
one to me.

(Although I wonder if part of the problem might be that too much
information is being provided in the RDF view, rather than using links
to other data that can be retrieved. Perhaps Michael could give an
example.)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Martin,

> b) download RDFa snippet that just represents the RDF/XML content (i.e. such
> that it does not have to be consolidated with the "presentation level" part
> of the Web page.

By coincidence, I just read this:

  Hidden div's -- don't do it!
  It can be tempting to add all the content relevant for a rich snippet
  in one place on the page, mark it up, and then hide the entire block
  of text using CSS or other techniques. Don't do this! Mark up the
  content where it already exists. Google will not show content from
  hidden div's in Rich Snippets, and worse, this can be considered
  cloaking by Google's spam detection systems. [1]

Regards,

Mark

[1] 
<http://knol.google.com/k/google-rich-snippets/google-rich-snippets/32la2chf8l79m/1#>

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Kingsley,

> If you are comfortable producing (X)HTML documents, then simply use RDFa and
> terms from relevant vocabularies to describe yourself, your needs, your
> offerings, and other things, clearly. Once you've done that, simply leave
> the Web to do the REST :-)
>
> Everything else is a technical detail (imho).

But that isn't the discussion we're having, IMHO.

We're not talking about how you or I might do it -- people comfortable
with .htaccess files, server configuration, and so on.

My understanding of the discussion that was going on, is that whilst
we all want to see the semantic web succeed (even if we all have a
different view of what the semantic web is), we're asking how exactly
it is that we can achieve it.

And for years, the solutions proposed have been somewhat mysterious;
RDF/XML, SPARQL end-points, N3, content negotiation, 303s, and so on.

You have to ask yourself at some point, do we want the data, or don't
we -- do we want people to publish stuff that we 'semwebbers' can use?
And if we do want it, then let's help them publish it.

I may be biased because I've had my nose pressed up against it for too
many years, but I believe that in this regards, RDFa is a
game-changer.

It's not GRDDL, which says 'publish whatever the hell you like and
we'll convert it'. It's not microformats, which says, 'here are a
handful of centralised vocabularies, for use on a decentralised web'.
And it's not RDF/XML, which requires you to take apart your server and
put it back together again.

It's HTML.

And everyone knows at least one way to publish HTML, don't they?

In the years that I've been involved with the RDFa work, the mental
model I have always had, is of someone using Blogger or Drupal or
something just as simple, to publish RDF. That's now possible with
RDFa, and what's even more exciting, Yahoo! and Google will pick it
up.

I realise I'm sounding like an evangelist (no doubt because I am one). :)

But my suggestion would be that we have a window of opportunity here,
to create a semantic infrastructure that is indistinguishable from the
web itself; the more metadata we can get into HTML-space, the more
likely we are to bring about a more 'semantic' web...before anyone
notices. ;)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation

[Mark Birbeck]

Hi Jeremy/Pat,

On Thu, Jun 25, 2009 at 10:16 PM, Jeremy Carroll wrote:
> Pat Hayes wrote:
>>
>> RDF should be text, in documents. One should be able to use it without
>> knowing about anything more than the RDF spec and the XML spec. If it
>> requires people to tinker with files with names starting with a dot, or
>> write code, or deploy scripts, then the entire SWeb architecture is
>> fundamentally broken.
>>
>
> Largely agreeing with you Pat, I think I would want to go a step further and
> say that you should be able to use RDF without knowing anything about the
> RDF spec or the XML spec, or any other spec. Web users are not required to
> read the specs.
>
> Using RDF includes publishing it. The "infrastructure" whatever that is
> should achieve the ability to publish my data in an appropriate way.

I guess what you're getting at here is the more general point about
tools hiding RDF, but I'd like to add some comments on HTML more
specifically.

HTML publishing really took off when it became easy for anyone to
publish. Originally that was word processors that converted their
output to HTML, but you still had to deploy your document to a server.

Then it was CMS systems that could be used as easily by small
businesses and schools as large corporations, but you still needed to
have a server.

Then it became blogs, where someone else did the server install, and
you just typed in the content.

Then it was wikis -- ditto.

Now it's Google Docs, Facebook pages, Tweets, and more.

In other words, publishing HTML just gets easier and easier, and
that's the infrastructure that's important -- the HTML publishing
infrastructure.

So to publish RDF, we should simply be leveraging that enormous infrastructure.

This theme was one of the major motivations for the creation of RDFa
(née RDF/XHTML), and I would say that it's an even more important
theme today; so much so that I made it the core of a presentation I
did at SemTech last week, on 'RDFa: The Semantic Web's Missing Link'.
[1].)

Regards,

Mark

[1] 
<http://webbackplane.com/mark-birbeck/blog/2009/06/slides-for-semtech2009-talk-on-rdfa>

-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: http://ld2sd.deri.org/lod-ng-tutorial/

[Mark Birbeck]

Hi Dan,

I'm afraid I don't completely follow the history of the discussion
that Martin is raising, but the reason he has included me on the CC
list is because during a chat at SemTech last week, he asked me what I
thought about owl:imports. I said that I was actually using it in my
RDFa processor; after parsing a document, the processor queries the
triple store to see if any of the triples have an owl:imports
predicate, and if they do, the referenced document is loaded.

I have no particular opinion on whether owl:imports is a good solution
or not. The reason I adopted it was because I wanted some way to
modularise the ontologies I was creating on argot-hub; for example, I
have some documents that contain nothing but a single SKOS collection,
and I thought it would be a good idea to allow those to be used in
other ontologies.

So, if owl:imports is wrong that's fine, but what then is best
practice for importing small parts of a document into a larger whole?
If you're not using owl:imports in FOAF, then what do you use?

Or is the general approach to put the whole ontology into one document
(which is not how I'd like to proceed)?

(Actually...I'm getting a horrible feeling that I'm going to be told
that people do owl:sameAs to reference one ontology within another --
i.e., one term at a time. I really hope not. :))

Regards,

Mark

On Mon, Jun 22, 2009 at 8:58 PM, Dan Brickley wrote:
> [snip]
>
> Yup, re owl:imports, I enthusiastically added it to the FOAF spec when some
> OWL WG insider suggested it was the right thing to use, and dutifully
> removed it when someone (I forget who in both cases - quite possibly same
> person!) a few years later told me it had fallen from fashion within the OWL
> scene.
>
> Re attitudes to OWL ... I do agree there have in the distant past (ie. last
> year!) been a few casually dismissive remarks around here regarding OWL.
> It's all too easy for a healthy enthusiasm for practical tools to trick us
> into seeing tools that we're not so familiar with as impractical. I'm happy
> to have read plenty of useful discussion here and nearby about how best to
> use or augment owl:sameAs. FOAF is a described using OWL. I expect some day
> in the not too distant future, Dublin Core Terms will be described in OWL
> too. And the community on public-lod@w3.org have been excellent champions of
> both. Things aren't too polarised, despite the occasional lapses into "them
> and us"-ism...
>
> Optimistically,
>
> Dan
>
>



-- 
Mark Birbeck, webBackplane

mark.birb...@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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Bijan,

>> An important difference between embedded RDF/XML and RDFa is that RDFa and
>> the xhtml can use the same "literals".
>
> ? That seems true for RDF/XML as well. Hence parseType=Literal. You can also
> hide literals, hence property attributes.

I think what Taylor is describing, is something like this:

  Taylor Cowan

which reuses the data.

This is very difficult to do using embedded RDF/XML.

In RDF/XML, the two ways to express a predicate are via an element:

  Taylor Cowan

or an attribute:

  

Since the first way would make the XHTML invalid (adding arbitrary
elements is very difficult to do), the second is preferred, since
HTML/XHTML processors should ignore attributes that they don't
recognise.

However, that would require a duplication of data:

  Taylor Cowan

RDFa is therefore more efficient than RDF/XML embedded in HTML.
(Hardly surprising, since as I point out in my other email, my first
version of RDFa was exactly to embed RDF/XML.)


>>  In other words, the text viewed by the human, and the text stored as the
>> literal object of a triple is the same.
>
> An option in RDF/XML.

I don't follow what you mean. Do you mean that people can viewing the
RDF/XML? Or do you mean that XHTML+RDF/XML is viewable? As I pointed
out above, the problem is that this is not valid:

  
Welcome to the blog of
Taylor Cowan
  

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Bijan,

> One funny aspect of RDF/XML, as I understand the history, is that some of
> the quirkier aspects of its design stemmed from the goal of being embedable
> in HTML (hence all the alternative forms) in a legacy browser compatible
> way.

That's interesting, I'd not heard that.

I did think though, that one of the things about the RDF/XML structure
was an attempt to enable many XML layouts to be interpreted as RDF.
But obviously that's enormously difficult.


> In this sense, RDFa aims to fulfill one of the RDF/XML goals that helped
> make it (somewhat) unsuitable to backend work (compare with NTriples).
>
> If at first you don't succeed, try again 10 years later ;)

Work actually began on RDFa 5 years ago, so the wait wasn't quite so
long before 'trying again'. :)

But it's interesting that you say all of this, since my first attempt
at putting metadata into HTML was to actually employ a subset of
RDF/XML, applied to HTML documents.

Part of the parsing rules for RDF/XML say that parsing can begin when
an @rdf:about is discovered, so I tried things like this:

  

  ...


  
...
  

  

The elements prior to the @rdf:about are ignored in RDF/XML parsers,
so it seemed that it might be possible to create XHTML+RDF/XML hybrids
this way. But ultimately, getting predicates was way too awkward, and
since the primary goal was to make it easy for people to publish
metadata, this was a show-stopper.

(Not to mention that having to use namespace prefixes on the attribute
names would probably have killed the whole thing.)

In the end it became easier to create a new set of HTML-specific
attributes that played the same role as the RDF/XML ones, but over
which we had complete control in terms of their meaning, position,
etc.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Tom,

> Mark, before the claim is completely withdrawn I can't help but add my
> 2p worth... ;) I've got to agree broadly that there are some compelling
> usage scenarios for RDFa, but lets not fall into the trap of assuming
> that RDFa is easy and that RDF/XML is hard. Hugh's scenario, or a RDB
> with D2R server, are nice examples of where simply pumping out RDF/XML
> is nice and straightforward.

Well, I should clarify a couple of things.

I do think that from a syntax point of view, RDFa is an easier route
in to RDF, than RDF/XML. Of course, so is Turtle, N3...in fact
*anything* is an easier route in to RDF than RDF/XML. :)

But I think what we're talking about is how to *publish* RDF, and what
is 'easier' or more difficult will depend on who you are, and what
infrastructure you have in place already.

If you have no infrastructure at all, then publishing RDFa is
obviously easier than publishing RDF/XML, since all you need to do is
get yourself a blog. If you have a bit of infrastructure, and limited
experience, then you could add RDFa to your web-site, so again it's a
little easier.

If you have an RDF back-end, then it's obviously *very* easy to
publish RDF/XML. And of course, if you have experience with data feeds
and the like, then you could easily create an RDF/XML data source
alongside your web-pages.

So I was by no means saying that RDFa is 'easy' and RDF/XML is 'hard'.
But what I am pointing out is that we should see a lot more metadata
on the web in the near future, because it is now possible to publish
it using well established publishing mechanisms.

And I'd imagine that is good news for those desirous of a 'semantic' web.


> As always it's a case of the right tool for the right job.

Yes.


> Regarding
> your other (admittedly unfounded) claim, there may be many more people
> who end up publishing RDF as RDFa, but collectively they may end up
> publishing far fewer triples in total than a small number of publishers
> with very large data sets who choose to use RDF/XML to expose data from
> backend DBs.

Sure. But there is nothing to say that you can't publish large
datasets using XHTML+RDFa, i.e., producing XHTML+RDFa documents that
are primarily intended for consumption by another server, rather than
a web browser.

Publishers might then choose to publish just one document type,
especially when it can be consumed by search engines like
SearchMonkey.

Once people realise this, it will be interesting to see how much the
RDF/XML format is used, going forwards.

(All unfounded conjecture on my part, of course. :))


> [snip]
>
>> There is no rdf:Graph type, and Tom didn't say there is one.
>> Tom used the words "RDF document" and "RDF graph"
>> synonymously, which is a bit sloppy.
>
> Cough. Not strictly true, Richard, although you interpreted my meaning
> correctly; RDF document would have been a better term to use.
>
> What I was getting at in my original message was the question of whether
> there are different statements we might wish to make about an HTML-only
> document compared to a straight RDF/XML document.

I looked at that in my other email, so won't say more here, since that
thread is still running.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Richard,

> For these reasons I have always viewed RDF/XML as 'scaffolding' that
> holds triples which can be about *anything* you like...anything, that
> is, except itself. :)

Sorry...mis-typed, as Hillary might say.

Obviously RDF can talk about RDF. :)

What I mean (which is hopefully clear in the rest of the other email),
is that an RDF/XML document can't hold triples about itself, since an
RDF/XML document is 'scaffolding' that 'dissolves' the moment you
interpret it, leaving you only the triples.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

le to say 'this graph was published by', in RDF/XML, i.e.,
>> to talk about the information resource itself, because you will always
>> be talking about whatever the RDF/XML itself is about.
>
> Huh? Of course it is possible to talk about information resources in RDF.
> Assume that this is the content of an RDF document published at
> http://example.com/my_rdf_document.rdf :
>
> http://example.com/my_rdf_document.rdf";>
>Richard
>2008-07-14
>...
> 
>
> This is an RDF document talking about itself. This is standard practice, you
> can find examples like this in the RDF spec, and everywhere in the wild.
> (Note that in the example, I could have used rdf:about="", because an empty
> URI is expanded to the URI of the document.)
>
>> But there is no reason that we could not enable this, and if we wanted
>> to go this route, RDFa+HTML allows it.
>
> It's equally possible in RDFa and RDF/XML, today.

Mmm...I don't agree. I agree that you can talk about information
resources, but I see RDF/XML as an odd type of information resource
that is 'pure' triples.

Of course, I could well be wrong. :)

But if I am, your scenario seems to fall foul of the whole information
resource/resource dilemma, so I'm having trouble seeing how that is
resolved. I'll illustrate why I think that RDF/XML cannot talk about
itself (in a kind of 'Godel's Incompleteness Theorem' sort of way).

Let's flip the whole thing on its head, to begin with. Let's say that
our RDF/XML document is referring to a car:

  http://cars.org/123456";>
BMW
2008-07-14
...
  

That's fine, and we could have hundreds of cars in our RDF/XML
document. However, let's stick to one car, and serve it from the same
URL as its subject. As you rightly say we can abbreviate the @about to
refer to the 'current document':

At http://cars.org/123456:

  
BMW
2008-07-14
...
  

Hopefully that is still so far so good. Now let's add your publisher
information:

At http://cars.org/123456:

  
BMW
Richard
2008-07-14
...
  

Why does dc:publisher suddenly apply to the document and not the car?

If it does, how did you (or your software) know to apply it that way?

And even if you knew that dc:publisher applies to documents, (a) how
do you know to apply it to the RDF/XML document, and not
<http://cars.org/123456> (which might be a document), and (b) even if
you can resolve that, how would you decide what to apply the dc:date
to? Should it apply to the car or to the RDF/XML document?

For these reasons I have always viewed RDF/XML as 'scaffolding' that
holds triples which can be about *anything* you like...anything, that
is, except itself. :)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Hugh,

> I was puzzled by the suggestion that I might duplicate the RDF in the page 
> that did
> a simple html rendering of the underlying RDF I was trying to publish.
> I would have thought that this is actually a Bad Thing, rather than a Good 
> Thing.

Obviously it depends on what you want to happen to your data.

If you're publishing from one of your servers to another, or using
some closed system, then obviously there is no reason to do more work
than necessary.

But if you are trying to publish metadata that will be consumed by
other services, then RDFa is an option that is attracting wider
interest. I'm working on a project to allow UK public sector jobs to
be published for wider consumption, and I can tell you, I'm not
looking at RDF/XML!

I'm looking primarily at RDFa in web-pages, a little Microformats for
compatibility with Google's social network processing and client-side
tools like Operator, and then Atom feeds with embedded RDFa for
consumption by services like SearchMonkey.


> And if we are talking about an RDF browser (as our pages are, albeit with a 
> clean URI
> that doesn't have the browser URI in it), getting it to include the RDF as 
> RDFa or whatever
> is even stranger; after all
> http://demo.openlinksw.com/rdfbrowser2/?uri%5B%5D=http%3A%2F%2Fos.rkbexplorer.com%2Fdescription%2Fosr70017765
> doesn't include the substantive RDF as RDFa, (or have a link rel to 
> http://os.rkbexplorer.com/data/osr70017765 for that matter) which 
> would be the
> equivalent.

I can't comment on that example, but ultimately there is no need for a
URL for an HTML+RDFa page to be any different to a normal one.

(Although I might have missed your point, here)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: RDFa + RDF/XML Considered Harmful? (was RE: Ordnance Survey data as Linked Data)

[Mark Birbeck]

Hi Tom,

> Question: is it worth creating a duplicate RDF graph by using RDFa in
> HTML documents, when there is also RDF/XML available just one  rel=".../> away, and at a distinct URI? Doesn't this RDFa + RDF/XML
> pattern complicate the RDF-consumption picture in general...

It's difficult to answer this definitively. However, one factor to
consider is that the technique you describe was *already* in existence
when work began on RDFa, some four or five years ago. (And, for that
matter, when work began on Microformats, too.)

Given that there were few uses of this technique, outside of
controlled environments, I don't think we can say that RDFa has made
the situation _more_ complicated, or that it will inhibit adoption.

And of course, I'm biased. :)

I would say that RDFa has made the situation an order of magnitude
_less_ complicated, since authors and developers now have an easier
way to publish metadata; as Kinglsey said, increasing the number of
ways to publish metadata increases the number of possible clients that
might consume the data:

>> I also forgot to mention obvous use of RDFa in the HTML doc
>> which broadens the range of rdf aware user agents tha
>> commence RDF discovery from HTML


One more thing on your comments:

> [snip]
>
> Does it not
> also complicate the picture of making provenance statements using named
> graphs, if the subject of the triple could be both an HTML document and
> an RDF graph?

Is it possible to distinguish a graph URI? I hadn't realised that. It
would certainly be a good idea to  have an rdf:Graph type, but I
hadn't realised that there was one.

However, is not an rdf:Graph a type of information resource? An
RDF/XML document delivered from a web server is both a document and a
graph, but we have chosen to ignore that in the RDF architecture; it's
not possible to say 'this graph was published by', in RDF/XML, i.e.,
to talk about the information resource itself, because you will always
be talking about whatever the RDF/XML itself is about.

But there is no reason that we could not enable this, and if we wanted
to go this route, RDFa+HTML allows it.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)

Re: Library of Congress Subject Headings as SKOS Linked Data

[Mark Birbeck]

 the collections at the Library of
>>>> Congress. It has been in active development since 1898, and was first
>>>> published in 1914 so that other libraries and bibliographic utilities
>>>> could use and adapt it. The lcsh.info service makes 266,857 subject
>>>> headings available as SKOS concepts, which amounts to 2,441,494
>>>> triples that are separately downloadable [3] (since there isn't a
>>>> SPARQL endpoint just yet).
>>>>
>>>> At the last SWDWG telecon some questions came up about the way
>>>> concepts are identified, and made available via HTTP. Since we're
>>>> hoping lcsh.info can serve as an implementation of SKOS for the W3C
>>>> recommendation process we want to make sure we do this
>>>
>>> right. So I was
>>>>
>>>> hoping interested members of the linked-data and SKOS communities
>>>> could take a look and make sure the implementation looks correct.
>>>>
>>>> Each concept is identified with a URI like:
>>>>
>>>> http://lcsh.info/sh95000541#concept
>>>>
>>>> When responding to requests for concept URIs, the server content
>>>> negotiates to determine which representation of the concept
>>>
>>> to return:
>>>>
>>>> - application/xhtml+xml
>>>> - application/json
>>>> - text/n3
>>>> - application/rdf+xml
>>>>
>>>> This is basically the pattern that Cool URIs for the Semantic Web
>>>> discusses as the Hash URI with Content Negotiation [4]. An additional
>>>> point that is worth mentioning is that the XHTML representation
>>>> includes RDFa, that also describes the concept.
>>>>
>>>> At the moment the LCSH/SKOS data is only linked to itself, through
>>>> assertions that involve skos:broader, skos:narrower, and
>>>
>>> skos:related.
>>>>
>>>> But the hope is that minting URIs for LCSH will allow it to be mapped
>>>> and/or linked to concepts in other vocabularies: dbpedia, geonames,
>>>> etc.
>>>>
>>>> Any feedback, criticisms, ideas are welcome either on either the
>>>> public-lod [5] or public-swd-wg [6] discussion lists.
>>>>
>>>> Thanks for reading this far!
>>>> //Ed
>>>>
>>>> [1] http://lcsh.info
>>>> [2] http://www.loc.gov/marc/
>>>> [3] http://lcsh.info/static/lcsh.nt
>>>> [4] http://www.w3.org/TR/cooluris/#hashuri
>>>> [5] http://lists.w3.org/Archives/Public/public-lod/
>>>> [6] http://lists.w3.org/Archives/Public/public-swd-wg/
>>>>
>>>
>>>
>>>
>
>
>



-- 
Mark Birbeck, webBackplane

[EMAIL PROTECTED]

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)