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

[kidehen]

Kingsley Idehen wrote:

>
> On 6/28/09 6:33 PM, "Tom Heath" <tom.heath@...> wrote:
>
>  
>> Hi Richard,
>>
>> 2009/6/25 Richard Cyganiak <richard@...>:
>>
>> <snip/>
>>
>>    
>>> (On the value of content negotiation in general: I think the key point is
>>> that any linked data URI intended for re-use, when put into a browser by the
>>> average person interested in linked data publishing, MUST return something
>>> human-readable. That's a hard requirement, otherwise people will never be
>>> confident about what a particular URI means and hence they won't re-use.
>>> That was the thinking behind the Cool URIs note when Leo and I wrote it a
>>> few years ago. In the past, the only way to get that effect was with content
>>> negotiation, so even though content negotiation is a pain, it's what we had
>>> to do. In the present, we have an alternative thanks to RDFa.
>>>      
>> Not disagreeing at all about the human readable requirement, but just
>> a question... in this scenario you describe, is there not a risk that
>> Joe User will enter that URI and come to the conclusion that it
>> identifies the document (or section thereof), rather than a thing
>> described in the document?
>>
>> Interested in your thoughts :)
>>
>> Tom.
>>
>>    
>
> Tom,
>
> Of course not, if dealing with an HTTP URI deployed in line with the Linked
> Data meme's deployment guidelines. In short, the user will encounter a
> document describing the Thing identified by the URI.
>
> The issue is not the document, but what it represents (metadata) and how it
> comes to be associated (implicitly) with the entity (resource) it describes
> via the entities URI.
>
> When all is said and done, the Linked Data meme has simply used HTTP to fix
> an age old problem: implicit association of an Entity with its Metadata
> within the context of distributed computing without any platform lock-in.
>
> Rewind back to pre. Web, then ask yourself: how did programmers refer to
> data objects and de-reference their representations (typically a proprietary
> language and platform specific data structure).
>
> Again, Linked Data is just about making what was platform specific, platform
> independent, via HTTP i.e., "data access by reference" and "data
> manipulation by values exposed by de-dereferenced data structures".
>
> We really need to keep this quite simple. There are zillions of people that
> understand "data access by reference" etc.. They also understand Metadata
> etc.. What they don't understand is how we sometimes *inadvertently* make
> this whole Linekd Data meme thing complex by not connecting the meme to what
> existed before the Web (which was actually created on a computer that
> already had a fully functional distributed object based OS etc..).
>
>
>
> Kingsley
>
>
>
>
>
>  

Tom,

Much short version.

If a user "Joe Web User" becomes fixated on the metadata document URI we
don't have a problem. I say this because the aforementioned document
will always act as a conduit to the URI of the entity it describes.
Thus, Linked Data aware user agents will always be able to figure this
out and get what they want.

The most important thing is that we add the metadata document to the
general mix on the Web. By this I mean: in addition to the basic HTML
document (which has no specificity re. metadata) and the standard
ability to lookup markup (via browsers for instance), we now have the
ability to lookup a metadata bearing document via a URI.

Keeping the URIs within scope of user agents is the single most
important thing, since doing this is what really makes the Linked Data
meme tick :-)

--


Regards,

Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com

[Martin Hepp (UniBW)]

Hi Tom:

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

We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level.

<body>
<h1>This is the car I want to sell</h1>
Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009

<span>
... my whole RDF in RDFa
 </span>
<body>

The advantage of that would be that

- you just have to maintain ONE file,
- data and metadata are close by, so the likelihood of being up to date increases, and
- at the same time, the code does not get too messy.
- Also - no problems setting up the server (*).
- Easy to create on-line tools that generate RDFa snippets for simple pasting.
- Yahoo and Google will most likely honor RDFa meta-data only.

Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g.  dates, country codes,...)

I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc.  Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description.

The main problem with my proposal is that there is the risk that Google considers this "cloaking" and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index.

A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or  nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those.

Best

Martin



Tom Heath wrote:

Martin,

2009/6/27 Martin Hepp (UniBW) martin.hepp@...:
  

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.

Tom.

  

[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Tom Heath]

Hi Martin,

2009/6/29 Martin Hepp (UniBW) <martin.hepp@...>:

> Hi Tom:
>
>>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.
>
> We seem to agree on the observation, but not on the conclusion. What I want
> and suggest is using RDFa also for exchanging a bit more complex RDF models
> / data by simply using a lot of div / span or whatever elements that
> represent the RDF part in the SAME document BUT NOT too closely linked with
> the presentation level.
>
> <body>
> <h1>This is the car I want to sell</h1>
> Actually, a pretty cool car, for only $1.000. Offer valid through July 31,
> 2009
>
> <span>
> ... my whole RDF in RDFa
>  </span>
> <body>
>
> The advantage of that would be that
>
> - you just have to maintain ONE file,
> - data and metadata are close by, so the likelihood of being up to date
> increases, and
> - at the same time, the code does not get too messy.
> - Also - no problems setting up the server (*).
> - Easy to create on-line tools that generate RDFa snippets for simple
> pasting.
> - Yahoo and Google will most likely honor RDFa meta-data only.
>
> Also note that often the literal values will be in content attributes
> anyway, because the string for the presentation is not suitable as meta-data
> content anyway (e.g.  dates, country codes,...)
>
> I think the approach sketched above would be a cheap and useful way of
> publishing RDF meta-data. It could work with CMS / blogging software etc.
> Imaging if we were able to allow eBay sellers to put GoodRelations meta-data
> directly into the open XHTML part of their product description.
>
> The main problem with my proposal is that there is the risk that Google
> considers this "cloaking" and may remove respective resources from their
> index (Mark raised that issue). If that risk was confirmed, we would really
> have a problem. Imagine me selling Semantic Web markup as a step beyond SEO
> ... and the first consequence of following my advice is being removed from
> the Google index.
>
> A second problem is that if the document contains nodes that have no
> counterpart on the presentation level (e.g. intermediate nodes for holding
> n-ary relations), then they will also not be dereferencable. The same holds
> for URIs or  nodes that are outside the scope of the actual RDFa / XHTML
> document - I see no simple way of serving neither XHTML nor RDF content for
> those.

These are exactly the reasons why I emphasise the limitations and ask
that we don't oversell the capabilities of any technology, RDFa
included.

Tom.

[kidehen]

Martin Hepp (UniBW) wrote:

> Hi Tom:
>
> >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.
> We seem to agree on the observation, but not on the conclusion. What I
> want and suggest is using RDFa also for exchanging a bit more complex
> RDF models / data by simply using a lot of div / span or whatever
> elements that represent the RDF part in the SAME document BUT NOT too
> closely linked with the presentation level.
>
> <body>
> <h1>This is the car I want to sell</h1>
> Actually, a pretty cool car, for only $1.000. Offer valid through July
> 31, 2009
>
> <span>
> ... my whole RDF in RDFa
>  </span>
> <body>
>
> The advantage of that would be that
>
> - you just have to maintain ONE file,
> - data and metadata are close by, so the likelihood of being up to
> date increases, and
> - at the same time, the code does not get too messy.
> - Also - no problems setting up the server (*).
> - Easy to create on-line tools that generate RDFa snippets for simple
> pasting.
> - Yahoo and Google will most likely honor RDFa meta-data only.
>
> Also note that often the literal values will be in content attributes
> anyway, because the string for the presentation is not suitable as
> meta-data content anyway (e.g.  dates, country codes,...)
>
> I think the approach sketched above would be a cheap and useful way of
> publishing RDF meta-data. It could work with CMS / blogging software
> etc.  Imaging if we were able to allow eBay sellers to put
> GoodRelations meta-data directly into the open XHTML part of their
> product description.
>
> The main problem with my proposal is that there is the risk that
> Google considers this "cloaking" and may remove respective resources
> from their index (Mark raised that issue). If that risk was confirmed,
> we would really have a problem. Imagine me selling Semantic Web markup
> as a step beyond SEO ... and the first consequence of following my
> advice is being removed from the Google index.
>
> A second problem is that if the document contains nodes that have no
> counterpart on the presentation level (e.g. intermediate nodes for
> holding n-ary relations), then they will also not be dereferencable.
> The same holds for URIs or  nodes that are outside the scope of the
> actual RDFa / XHTML document - I see no simple way of serving neither
> XHTML nor RDF content for those.

Martin,

If Google doesn't see invisible DIVs as cloaking, the issue vaporizes.

Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa)
approach they will at least remain in the Google index via usual SEO
oriented keyword gimmickry, albeit generally suboptimal.

If we make a recipe doc showcasing these issues, we will more than
likely get Google to recalibrate back to the Web; especially if we can
demonstrate that other search engine players --that have support RDFa --
not being afflicted with the same cloaking myopia.

Kingsley

>
> Best
>
> Martin
>
>
>
> Tom Heath wrote:
>> Martin,
>>
>> 2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:
>>  
>>> 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.
>>
>> Tom.
>>
>>  
>
> --
> --------------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  mhepp@...
> phone:   [phone]
> fax:     [phone]
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
> ========================================================================
>
> Webcast:
> http://www.heppnetz.de/projects/goodrelations/webcast/
>
> Talk at the Semantic Technology Conference 2009:
> "Semantic Web-based E-Commerce: The GoodRelations Ontology"
> http://tinyurl.com/semtech-hepp
>
> Tool for registering your business:
> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>
> Overview article on Semantic Universe:
> http://tinyurl.com/goodrelations-universe
>
> Project page and resources for developers:
> http://purl.org/goodrelations/
>
> Tutorial materials:
> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey
>
> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>
>
>
>  

--


Regards,

Kingsley Idehen      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software     Web: http://www.openlinksw.com

[Yihong Ding]

Hi Kingley and Martin,

A potential problem of the model Martin suggested is that the same data has to be presented at least TWICE in one document. Although the RDFa portion of the data is supposed to be automatically generated, it, however, does not prohibit anybody from manually revising it. Therefore, it leaves a huge hole for the hackers (or anybody who want to do some deceptive job). In our imperfect world, this problem is severe.

Adding an extra layer of data mapping always causes additional work on data maintenance. This time, the extra work could be a nightmare though the architecture is neat.

yihong

On Mon, Jun 29, 2009 at 8:03 AM, Kingsley Idehen <kidehen@...> wrote:

Martin Hepp (UniBW) wrote:

Hi Tom:

>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.
We seem to agree on the observation, but not on the conclusion. What I want and suggest is using RDFa also for exchanging a bit more complex RDF models / data by simply using a lot of div / span or whatever elements that represent the RDF part in the SAME document BUT NOT too closely linked with the presentation level.

<body>
<h1>This is the car I want to sell</h1>
Actually, a pretty cool car, for only $1.000. Offer valid through July 31, 2009

<span>
... my whole RDF in RDFa
 </span>
<body>

The advantage of that would be that

- you just have to maintain ONE file,
- data and metadata are close by, so the likelihood of being up to date increases, and
- at the same time, the code does not get too messy.
- Also - no problems setting up the server (*).
- Easy to create on-line tools that generate RDFa snippets for simple pasting.
- Yahoo and Google will most likely honor RDFa meta-data only.

Also note that often the literal values will be in content attributes anyway, because the string for the presentation is not suitable as meta-data content anyway (e.g.  dates, country codes,...)

I think the approach sketched above would be a cheap and useful way of publishing RDF meta-data. It could work with CMS / blogging software etc.  Imaging if we were able to allow eBay sellers to put GoodRelations meta-data directly into the open XHTML part of their product description.

The main problem with my proposal is that there is the risk that Google considers this "cloaking" and may remove respective resources from their index (Mark raised that issue). If that risk was confirmed, we would really have a problem. Imagine me selling Semantic Web markup as a step beyond SEO ... and the first consequence of following my advice is being removed from the Google index.

A second problem is that if the document contains nodes that have no counterpart on the presentation level (e.g. intermediate nodes for holding n-ary relations), then they will also not be dereferencable. The same holds for URIs or  nodes that are outside the scope of the actual RDFa / XHTML document - I see no simple way of serving neither XHTML nor RDF content for those.

Martin,

If Google doesn't see invisible DIVs as cloaking, the issue vaporizes.

Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa) approach they will at least remain in the Google index via usual SEO oriented keyword gimmickry, albeit generally suboptimal.

If we make a recipe doc showcasing these issues, we will more than likely get Google to recalibrate back to the Web; especially if we can demonstrate that other search engine players --that have support RDFa -- not being afflicted with the same cloaking myopia.

Kingsley

Best

Martin



Tom Heath wrote:

Martin,

2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:
 

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.

Tom.

 

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
        http://www.heppnetz.de/ (personal)
skype:   mfhepp twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009: "Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009



 

--


Regards,

Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO OpenLink Software     Web: http://www.openlinksw.com

--
===================================
Yihong Ding

http://yihongs-research.blogspot.com/

[Mark Birbeck-4]

Hi Tom,

On Sun, Jun 28, 2009 at 11:46 PM, Tom Heath<tom.heath@...> wrote:

> Martin,
>
> 2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:
>> 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.birbeck@...

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)

[Martin Hepp (UniBW)]

Hi Yihong:
I am a big fan of Codd's "one fact in one place" credo. However, in this
particular case, that principle is violated anyway, since the literal
values are often duplicated for presentation and meta-data prupolses
anyway (think of "2009-06-29" vs. "June 29, 2009"). Second, for dynamic
Web apps, it does not really matter whether the same fact is exposed
once or twice, since the central location is one place in the database
anyway. Third, this is the only way how a tool like the GoodRelations
annotator [1] can create RDFa snippets for simple copy-and-paste into
existing pages.

Also note that in the particular case of RDFa, the principle of "one
fact in one place" clashes with the "separation of concerns" principle,
in particular, that of keeping data and presentation separate.

The textbook-style "beauty of simplicity" of RDFa holds for adding a
dc:creator property to a string value that is the same for presentation
and at the data level. 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.

As far as security is concerned: I there is no real difference in my
proposal, as the "content" attribute of RDFa allows serving different
data to human and to machines, and this is a needed feature anyway.
Digital signatures at the document or element level and / or data
provenance approached will likely cater for that.

Best

Martin

Yihong Ding wrote:

> Hi Kingley and Martin,
>
> A potential problem of the model Martin suggested is that the same data has
> to be presented at least TWICE in one document. Although the RDFa portion of
> the data is supposed to be automatically generated, it, however, does not
> prohibit anybody from manually revising it. Therefore, it leaves a huge hole
> for the hackers (or anybody who want to do some deceptive job). In our
> imperfect world, this problem is severe.
>
> Adding an extra layer of data mapping always causes additional work on data
> maintenance. This time, the extra work could be a nightmare though the
> architecture is neat.
>
> yihong
>
>
> On Mon, Jun 29, 2009 at 8:03 AM, Kingsley Idehen <kidehen@...>wrote:
>
>  
>> Martin Hepp (UniBW) wrote:
>>
>>    
>>> Hi Tom:
>>>
>>>      
>>>> 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.
>>>>        
>>> We seem to agree on the observation, but not on the conclusion. What I
>>> want and suggest is using RDFa also for exchanging a bit more complex RDF
>>> models / data by simply using a lot of div / span or whatever elements that
>>> represent the RDF part in the SAME document BUT NOT too closely linked with
>>> the presentation level.
>>>
>>> <body>
>>> <h1>This is the car I want to sell</h1>
>>> Actually, a pretty cool car, for only $1.000. Offer valid through July 31,
>>> 2009
>>>
>>> <span>
>>> ... my whole RDF in RDFa
>>>  </span>
>>> <body>
>>>
>>> The advantage of that would be that
>>>
>>> - you just have to maintain ONE file,
>>> - data and metadata are close by, so the likelihood of being up to date
>>> increases, and
>>> - at the same time, the code does not get too messy.
>>> - Also - no problems setting up the server (*).
>>> - Easy to create on-line tools that generate RDFa snippets for simple
>>> pasting.
>>> - Yahoo and Google will most likely honor RDFa meta-data only.
>>>
>>> Also note that often the literal values will be in content attributes
>>> anyway, because the string for the presentation is not suitable as meta-data
>>> content anyway (e.g.  dates, country codes,...)
>>>
>>> I think the approach sketched above would be a cheap and useful way of
>>> publishing RDF meta-data. It could work with CMS / blogging software etc.
>>>  Imaging if we were able to allow eBay sellers to put GoodRelations
>>> meta-data directly into the open XHTML part of their product description.
>>>
>>> The main problem with my proposal is that there is the risk that Google
>>> considers this "cloaking" and may remove respective resources from their
>>> index (Mark raised that issue). If that risk was confirmed, we would really
>>> have a problem. Imagine me selling Semantic Web markup as a step beyond SEO
>>> ... and the first consequence of following my advice is being removed from
>>> the Google index.
>>>
>>> A second problem is that if the document contains nodes that have no
>>> counterpart on the presentation level (e.g. intermediate nodes for holding
>>> n-ary relations), then they will also not be dereferencable. The same holds
>>> for URIs or  nodes that are outside the scope of the actual RDFa / XHTML
>>> document - I see no simple way of serving neither XHTML nor RDF content for
>>> those.
>>>
>>>      
>> Martin,
>>
>> If Google doesn't see invisible DIVs as cloaking, the issue vaporizes.
>>
>> Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa) approach
>> they will at least remain in the Google index via usual SEO oriented keyword
>> gimmickry, albeit generally suboptimal.
>>
>> If we make a recipe doc showcasing these issues, we will more than likely
>> get Google to recalibrate back to the Web; especially if we can demonstrate
>> that other search engine players --that have support RDFa -- not being
>> afflicted with the same cloaking myopia.
>>
>> Kingsley
>>
>>    
>>> Best
>>>
>>> Martin
>>>
>>>
>>>
>>> Tom Heath wrote:
>>>
>>>      
>>>> Martin,
>>>>
>>>> 2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:
>>>>
>>>>
>>>>        
>>>>> 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.
>>>>
>>>> Tom.
>>>>
>>>>
>>>>
>>>>        
>>> --
>>> --------------------------------------------------------------
>>> martin hepp
>>> e-business & web science research group
>>> universitaet der bundeswehr muenchen
>>>
>>> e-mail:  mhepp@...
>>> phone:   [phone]
>>> fax:     [phone]
>>> www:     http://www.unibw.de/ebusiness/ (group)
>>>         http://www.heppnetz.de/ (personal)
>>> skype:   mfhepp twitter: mfhepp
>>>
>>> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
>>> ========================================================================
>>>
>>> Webcast:
>>> http://www.heppnetz.de/projects/goodrelations/webcast/
>>>
>>> Talk at the Semantic Technology Conference 2009: "Semantic Web-based
>>> E-Commerce: The GoodRelations Ontology"
>>> http://tinyurl.com/semtech-hepp
>>>
>>> Tool for registering your business:
>>> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>>>
>>> Overview article on Semantic Universe:
>>> http://tinyurl.com/goodrelations-universe
>>>
>>> Project page and resources for developers:
>>> http://purl.org/goodrelations/
>>>
>>> Tutorial materials:
>>> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A
>>> Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo!
>>> SearchMonkey
>>>
>>> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>>>
>>>
>>>
>>>
>>>
>>>      
>> --
>>
>>
>> Regards,
>>
>> Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen<http://www.openlinksw.com/blog/%7Ekidehen>
>> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>>
>>
>>
>>
>>
>>
>>    
>
>
>  

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
          http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A
Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo!
SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009






[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Toby Inkster-4]

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:

<div xmlns:dc="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">
  <span property="dc:creator">Mark Birkbeck</span> says that
  <span rel="rdf:subject" resource="[db:Sky]">the sky</span>
  <span rel="rdf:predicate" resource="http://dbpedia.org/property/color"
      >is</span>
  <span rel="rdf:object" resource="[db:Blue]">blue</span>.
</div>

And an example of a list can be found here:

http://ontologi.es/rail/routes/gb/VTB1.xhtml

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Yihong Ding]

Hi Martin,

I agree to most of your opinions, especially the architecture of data representation you suggest. The only point I would like to emphasize is to figure out a way that eliminates the demand of storing a fact multiple times. Even though you think that it might be inevitable, personally I still believe the possibility.

A typical analogical example is the CSS. CSS is a great example for data displaying. By using CSS, we do not have to store the same data multiple times but simultaneously reach the goal of flexible data display. Well, certainly CSS is not directly applicable in the semantic realm. But I believe it is the right way of thinking we need to approach.

Actually, the philosophy of Microformat is closer to CSS though Microformat is much more limited a mechanism. I envision an innovation of semantic data display combining the strengthes of Microformat and RDFa/RDF. But it is surely not easy.

BTW: I like your work on GoodRelations. I am now working on the radiological medicine domain and trying to develop something like it. (And indeed data display is a critical issue for me to solve in the project.) Hopefully we may have some chances to cooperate in the future again.

cheers,

yihong

On Mon, Jun 29, 2009 at 9:01 AM, Martin Hepp (UniBW) <martin.hepp@...> wrote:

Hi Yihong:
I am a big fan of Codd's "one fact in one place" credo. However, in this
particular case, that principle is violated anyway, since the literal
values are often duplicated for presentation and meta-data prupolses
anyway (think of "2009-06-29" vs. "June 29, 2009"). Second, for dynamic
Web apps, it does not really matter whether the same fact is exposed
once or twice, since the central location is one place in the database
anyway. Third, this is the only way how a tool like the GoodRelations
annotator [1] can create RDFa snippets for simple copy-and-paste into
existing pages.

Also note that in the particular case of RDFa, the principle of "one
fact in one place" clashes with the "separation of concerns" principle,
in particular, that of keeping data and presentation separate.

The textbook-style "beauty of simplicity" of RDFa holds for adding a
dc:creator property to a string value that is the same for presentation
and at the data level. 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.

As far as security is concerned: I there is no real difference in my proposal, as the "content" attribute of RDFa allows serving different data to human and to machines, and this is a needed feature anyway. Digital signatures at the document or element level and / or data provenance approached will likely cater for that.

Best

Martin

Yihong Ding wrote:

Hi Kingley and Martin,

A potential problem of the model Martin suggested is that the same data has
to be presented at least TWICE in one document. Although the RDFa portion of
the data is supposed to be automatically generated, it, however, does not
prohibit anybody from manually revising it. Therefore, it leaves a huge hole
for the hackers (or anybody who want to do some deceptive job). In our
imperfect world, this problem is severe.

Adding an extra layer of data mapping always causes additional work on data
maintenance. This time, the extra work could be a nightmare though the
architecture is neat.

yihong


On Mon, Jun 29, 2009 at 8:03 AM, Kingsley Idehen <kidehen@...>wrote:

 

Martin Hepp (UniBW) wrote:

   

Hi Tom:

     

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.
       

We seem to agree on the observation, but not on the conclusion. What I
want and suggest is using RDFa also for exchanging a bit more complex RDF
models / data by simply using a lot of div / span or whatever elements that
represent the RDF part in the SAME document BUT NOT too closely linked with
the presentation level.

<body>
<h1>This is the car I want to sell</h1>
Actually, a pretty cool car, for only $1.000. Offer valid through July 31,
2009

<span>
... my whole RDF in RDFa
 </span>
<body>

The advantage of that would be that

- you just have to maintain ONE file,
- data and metadata are close by, so the likelihood of being up to date
increases, and
- at the same time, the code does not get too messy.
- Also - no problems setting up the server (*).
- Easy to create on-line tools that generate RDFa snippets for simple
pasting.
- Yahoo and Google will most likely honor RDFa meta-data only.

Also note that often the literal values will be in content attributes
anyway, because the string for the presentation is not suitable as meta-data
content anyway (e.g.  dates, country codes,...)

I think the approach sketched above would be a cheap and useful way of
publishing RDF meta-data. It could work with CMS / blogging software etc.
 Imaging if we were able to allow eBay sellers to put GoodRelations
meta-data directly into the open XHTML part of their product description.

The main problem with my proposal is that there is the risk that Google
considers this "cloaking" and may remove respective resources from their
index (Mark raised that issue). If that risk was confirmed, we would really
have a problem. Imagine me selling Semantic Web markup as a step beyond SEO
... and the first consequence of following my advice is being removed from
the Google index.

A second problem is that if the document contains nodes that have no
counterpart on the presentation level (e.g. intermediate nodes for holding
n-ary relations), then they will also not be dereferencable. The same holds
for URIs or  nodes that are outside the scope of the actual RDFa / XHTML
document - I see no simple way of serving neither XHTML nor RDF content for
those.

     

Martin,

If Google doesn't see invisible DIVs as cloaking, the issue vaporizes.

Also, if people take the SEO + SDQ (Linked Data Expressed in RDFa) approach
they will at least remain in the Google index via usual SEO oriented keyword
gimmickry, albeit generally suboptimal.

If we make a recipe doc showcasing these issues, we will more than likely
get Google to recalibrate back to the Web; especially if we can demonstrate
that other search engine players --that have support RDFa -- not being
afflicted with the same cloaking myopia.

Kingsley

   

Best

Martin



Tom Heath wrote:

     

Martin,

2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:


       

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.

Tom.



       

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
       http://www.heppnetz.de/ (personal)
skype:   mfhepp twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009: "Semantic Web-based
E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A
Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo!
SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009





     

--


Regards,

Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen<http://www.openlinksw.com/blog/%7Ekidehen>
President & CEO OpenLink Software     Web: http://www.openlinksw.com






   

 

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
        http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009

--
===================================
Yihong Ding

http://yihongs-research.blogspot.com/

[Mark Birbeck-4]

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* <meta>
and <link> properties. However, some browsers thought they were doing
us a favour by moving the <meta> and <link> elements out of the <body>
and into the <head>, 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 <ol>, <ul>, and <li>, 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<tai@...> 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:
>
> <div xmlns:dc="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">
>  <span property="dc:creator">Mark Birkbeck</span> says that
>  <span rel="rdf:subject" resource="[db:Sky]">the sky</span>
>  <span rel="rdf:predicate" resource="http://dbpedia.org/property/color"
>      >is</span>
>   <span rel="rdf:object" resource="[db:Blue]">blue</span>.
> </div>
>
> And an example of a list can be found here:
>
> http://ontologi.es/rail/routes/gb/VTB1.xhtml
>
> --
> Toby A Inkster
> <mailto:mail@...>
> <http://tobyinkster.co.uk>
>
>

--
Mark Birbeck, webBackplane

mark.birbeck@...

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)

[Mark Birbeck-4]

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

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)

[Yihong Ding]

Thank you, Toby.  The EASE is an interesting proposal. As I have said, we at Fuji are now actively looking for a convenient and efficiently way of displaying semantic data. I need to study more of this EASE project. If possible, I would like to have more discussion with you of the topic in the future.

best,

yihong

On Mon, Jun 29, 2009 at 10:11 AM, Toby Inkster <mail@...> wrote:

On Mon, 2009-06-29 at 09:46 -0400, Yihong Ding wrote:
> I envision an innovation of semantic data display combining the
> strengthes of Microformat and RDFa/RDF. But it is surely not easy.

It's not easy, it's EASE. ;-)

http://buzzword.org.uk/2008/rdf-ease/spec

Note to myself: chapter 1 needs fleshing out with some examples.

--

Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

--
===================================
Yihong Ding

http://yihongs-research.blogspot.com/

[Tom Heath]

Hi Mark,

2009/6/29 Mark Birbeck <mark.birbeck@...>:

> Hi Tom,
>
> On Sun, Jun 28, 2009 at 11:46 PM, Tom Heath<tom.heath@...> wrote:
>> Martin,
>>
>> 2009/6/27 Martin Hepp (UniBW) <martin.hepp@...>:
>>> 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.

Just in case there's any doubt, let me clarify that this isn't an
anti-RDFa position from me, just trying to unpack the issue.

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

Absolutely agreed. I don't dispute this at all. Though it's not really
my point. See below...

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

In some cases. It depends on the publishing architecture. What effect
does it have on the maintenance cost of the layout/structural markup
of the page?

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

Yes, this is exactly how I understood his point. It's also exactly why
I keep banging on about us not saying that x is better than y. It's
not about a limitation of RDFa as a technology (apologies if it came
across that way), simply a reflection of the fact that it can be
challenging to deploy in some circumstances. Again, this is context
dependent, and the best solution can only be determined by examining
that context.

> I don't think that this is a flaw in RDFa itself,

Agreed.

> and I'm not convinced that there is an easy solution in the form of another
> technology that would solve this.

Well, such cases may justify the 303/conneg pattern.

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

Completely agreed on this point. You'll see this approach manifested
in Revyu.com, where there is redundancy in data between HTML pages for
the sake of presenting human users with a more complete view (without
requiring them to visit multiple pages); the same is not true of the
(broadly) equivalent RDF documents, where I tried to avoid redundancy,
on the basis that any SW agent worth it's salt should be able to
dereference the referenced URIs to retrieve the data it needs. IIRC
others disagree with my approach here (TimBL? Richard C?), but this
speaks completely to the question of what is the appropriate
interaction paradigm for apps built on the Web of Data. If we can
understand the answers to this question then it may help guide our
deployment strategies for RDFa.

Cheers,

Tom.

[Pat Hayes]

On Jun 28, 2009, at 6:39 PM, Tim Berners-Lee wrote:

>
> On 2009-06 -25, at 13:29, Pat Hayes wrote:
>
>>
>> On Jun 25, 2009, at 11:44 AM, Martin Hepp (UniBW) wrote:
>>
>>> Hi all:
>>>
>>> After about two months of helping people generate RDF/XML metadata  
>>> for their businesses using the GoodRelations annotator [1],
>>> I have quite some evidence that the current best practices of  
>>> using .htaccess are a MAJOR bottleneck for the adoption of  
>>> Semantic Web technology.
>>
>> I agree, and raised this issue with the W3C TAG some time ago. It  
>> was apparently not taken seriously. The general consensus seemed to  
>> be that any normal adult should be competent to manipulate an  
>> Apache server.
>
> (Was yours a deliberate sarcastic misrepresentation of the TAG's  
> consensus, or a genuine misunderstanding?

A genuine misunderstanding, based on the personal feedback I got, I  
admit, rather than a careful perusal of the TAG published decisions,  
my bad.

> )   The TAG has expressed that the fact that Apache needs root  
> intervention when it doesn't have the right mime type set up is a  
> serious bug.

Well, Im glad to hear that, and apologize for not knowing it. But as I  
said in my reply to Tom, that doesn't help me actually use the SWeb  
from out here in the one-way side roads off the information  
superhighway.

>
>> My own company, however, refuses to allow its employees to have  
>> access to .htaccess files, and I am therefore quite unable to  
>> conform to the current best practice from my own work situation. I  
>> believe that this situation is not uncommon.
>
> So you mean you can't set up content negotiation and redirection.

Right. As I discovered when I was trying to follow the http-range-14  
decision and experiment with my notorious 'PatHayes' self-referential  
page, in order to bring it into line with the recommendations. Talk  
about eating dog food...

> But you can use foo#bar URIs like I do.

True.

>
> Will the company allow a mime.types file to include application/rdf
> +xml?

No problem there, AFAIK.

Pat

>
> Tim
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Pat Hayes]

On Jun 28, 2009, at 6:20 PM, Tom Heath wrote:

> Hi Pat,
>
> 2009/6/25 Pat Hayes <phayes@...>:
>> With the sincerest respect, Tom, your attitude here is part of the  
>> problem.
>> Maybe, along with many other people, I am indeed still stuck in the
>> mid-1990s. You have permission to be as condescending as you like.  
>> But
>> still, here I am, stuck. Thoroughly stuck. So no amount of  
>> condescending
>> "sooo-20th-century, my dear" chatter is going to actually enable me  
>> to get
>> to a place where I can do what you think I should be doing.
>
> Condescension was never my intention here. My goal was to draw a
> comparison that might enable us to learn a lesson from the history of
> the Web and use that to help us move forward. As Mark described, over
> the course of time more and more tools became available that made it
> easier to publish HTML. Presumably these only arose because publishing
> HTML was to some degree hard. The Web community has gone through this
> process once already; let's learn the lessons from last time and apply
> them to publishing RDF so people don't have to be stuck any more.

Um.. I thought that was MY point :-)

> Dan
> outlined some technical approaches to doing this sort of thing. Some
> domain-specific apps already exist that (hopefully) reduce the pain;
> it was one of the goals of Revyu.com for example.
>
>> I cannot use a
>> rewrite rule to catch incoming requests, or do whatever you are  
>> talking
>> about here. I live in an environment where I simply do not have  
>> access at
>> all to the workings of my server at a level that close to the  
>> metal, because
>> it is already woven into a clever maze of PHP machinery which is  
>> too fragile
>> to allow erks like me to mess with it. Some of the best W3C techies  
>> have
>> taken a look, and they can't find a way through it, either. Maybe  
>> Im in a
>> special position, but I bet a whole lot of people, especially in the
>> corporate world, are in a similar bind.
>
> You're talking about two very different groups here. If the right
> tools are created then individuals will presumably adopt some
> specialised SaaS analogous to say wordpress.com. Corporations are a
> different kettle of fish

I work for a small research company which happens to have an ambitious  
Webmaster and a Director who is sensitive to visual graphics and Web  
image issues. The result is a maze of complex PHP giving users a very  
nice experience, but not conducive to transparent use by its  
inhabitants. Just from casual Web browsing, I cannot believe that I am  
in a very small minority. There are a lot of 'sexy' sites out there  
that must be in a similar state. I know that several 'web authoring'  
systems produce similar PHP mazes, because Ive tried using them and  
then editing the output they produce, an experience rather like  
debugging BCPL.

> , but just as many built their own Web-serving
> infrastructure in the 90s, so they will invest in publishing data to
> the Semantic Web if they perceive adequate value (demonstrating that
> value is where we need to be working even harder!).
>
>> System level access to a server is
>> quite a different beast than being allowed to publish HTML on a  
>> website
>> somewhere. I can, and do, publish HTML, or indeed just about any  
>> file I
>> like, but I don't get to insert code. So 6 lines or 600, it makes no
>> difference.
>>
>> But in any case, this is ridiculous. RDF is just XML text, for  
>> goodness
>> sake.  I need to insert lines of code into a server file,  and  
>> write PHP
>> scripts, in order to publish some RDF or HTML?  That is insane. It  
>> would
>> have been insane in the mid-1990s and its even more insane now.
>
> No. This is incorrect. This discussion only applies to the
> 303-redirect/slash URI pattern. You can avoid this completely by using
> the hash URI pattern as someone mentioned (sorry for not crediting
> directly, getting hard to navigate this thread).

Yes, of course, and I apologize for overstating the case. Still, the  
slash-URI seems to be much more acceptable to many unsemantic Webbies,  
who are used to thinking of URIs as being stripped of their post-hash  
content at the slightest internet shiver, so don't regard a name  
including a hash as something 'real'; and it is the case about which  
all the fuss is being made. If the published advice was: always use  
hash URI patterns, I would be happy. But the published advice *starts*  
with 303 redirects and .htaccess file modifications.

>
>> IMO, it is
>> you (and Tim and the rest of the W3C) who are stuck in the past  
>> here.  Most
>> Web users do not, and will not, write code. They will be publishing  
>> content
>> in a cloud somewhere, even further away from the gritty world of  
>> scripts and
>> lines of code than people - most people - are now. Most actual  
>> content
>> providers are never going to want to even know that PHP scripts  
>> exist, let
>> alone be obliged to write or copy one.
>
> You've over-interpreted my words here. See above.

If so, I apologise. But think of what Im saying as a cry for help.  
There are a lot of people like me, I suspect, who would really like to  
help with SW deployment and are willing to write RDFa content, but are  
paralyzed by the apparent need to become Web-server hackers in order  
to do so. It just feels *wrong*. Your own metaphor is apt:

>
>> Martin is exactly right: this is a
>> MAJOR bottleneck to SWeb adoption. Its up to the people in the TAG  
>> to listen
>> to this fact and do something about it, not to keep issuing  
>> useless  'best
>> practice' advice that cannot be followed by 99% of the world.
>
> I think that's overplaying things. It's like saying "stop issuing best
> practices for cardiac surgeons because Average Joe can't use those to
> help improve his cardiac health".

Well, yes, exactly. Im not a cardiac surgeon, and here I am reading  
this stuff that I naively took to be good advice for improving my  
cardiac health. It didn't say: For Surgeons Only on the cover. If the  
SWeb is going to rely on cardiac surgeons rather then average Joes to  
get all that RDFa written, then its never going to happen.

>
>> 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.
>
> The architecture of the Semantic Web is the architecture of Web. And
> just as in the Web we have varied publishing patterns/workflows
> (ranging from simple to hard), so we will in the Semantic Web.

But, and this is where this thread started, right now we don't seem to  
have any easy ones at all. All my yelling has been to try to get you  
guys to take this issue as seriously as I think it deserves to be taken.

Best wishes

Pat

>
> Cheers,
>
> Tom.
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[David Booth-6]

On Mon, 2009-06-29 at 01:20 +0200, Tom Heath wrote:
> [ . . . ] This discussion only applies to the
> 303-redirect/slash URI pattern. You can avoid this completely by using
> the hash URI pattern . . . .

And as a reminder, you can also use a 303-redirect service if you cannot
configure your server, such as:
http://thing-described-by.org/ 

For example,
http://thing-described-by.org?http://dbooth.org/2005/dbooth/
does a 303 redirect to
http://dbooth.org/2005/dbooth/
That last one doesn't happen to serve RDF, but it certainly could.


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Tom Heath]

Hi Pat,

OK, yelling heard loud and clear :)

By way of concrete actions, I gave Ivan Herman a (probably unfairly)
hard time today here at Dagstuhl to 'encourage' the authors of the
Vocabs Best Practices to press on with the revision of that document
that addresses the current issues. An update of the "How to Publish
Linked Data on the Web" tutorial is also on the cards; perhaps one of
the outcomes of this revision could be a greater emphasis on the hash
URI pattern (and maybe also the 'health warning' you describe ;).

Cheers,

Tom.


2009/6/29 Pat Hayes <phayes@...>:

>
> On Jun 28, 2009, at 6:20 PM, Tom Heath wrote:
>
>> Hi Pat,
>>
>> 2009/6/25 Pat Hayes <phayes@...>:
>>>
>>> With the sincerest respect, Tom, your attitude here is part of the
>>> problem.
>>> Maybe, along with many other people, I am indeed still stuck in the
>>> mid-1990s. You have permission to be as condescending as you like. But
>>> still, here I am, stuck. Thoroughly stuck. So no amount of condescending
>>> "sooo-20th-century, my dear" chatter is going to actually enable me to
>>> get
>>> to a place where I can do what you think I should be doing.
>>
>> Condescension was never my intention here. My goal was to draw a
>> comparison that might enable us to learn a lesson from the history of
>> the Web and use that to help us move forward. As Mark described, over
>> the course of time more and more tools became available that made it
>> easier to publish HTML. Presumably these only arose because publishing
>> HTML was to some degree hard. The Web community has gone through this
>> process once already; let's learn the lessons from last time and apply
>> them to publishing RDF so people don't have to be stuck any more.
>
> Um.. I thought that was MY point :-)
>
>> Dan
>> outlined some technical approaches to doing this sort of thing. Some
>> domain-specific apps already exist that (hopefully) reduce the pain;
>> it was one of the goals of Revyu.com for example.
>>
>>> I cannot use a
>>> rewrite rule to catch incoming requests, or do whatever you are talking
>>> about here. I live in an environment where I simply do not have access at
>>> all to the workings of my server at a level that close to the metal,
>>> because
>>> it is already woven into a clever maze of PHP machinery which is too
>>> fragile
>>> to allow erks like me to mess with it. Some of the best W3C techies have
>>> taken a look, and they can't find a way through it, either. Maybe Im in a
>>> special position, but I bet a whole lot of people, especially in the
>>> corporate world, are in a similar bind.
>>
>> You're talking about two very different groups here. If the right
>> tools are created then individuals will presumably adopt some
>> specialised SaaS analogous to say wordpress.com. Corporations are a
>> different kettle of fish
>
> I work for a small research company which happens to have an ambitious
> Webmaster and a Director who is sensitive to visual graphics and Web image
> issues. The result is a maze of complex PHP giving users a very nice
> experience, but not conducive to transparent use by its inhabitants. Just
> from casual Web browsing, I cannot believe that I am in a very small
> minority. There are a lot of 'sexy' sites out there that must be in a
> similar state. I know that several 'web authoring' systems produce similar
> PHP mazes, because Ive tried using them and then editing the output they
> produce, an experience rather like debugging BCPL.
>
>> , but just as many built their own Web-serving
>> infrastructure in the 90s, so they will invest in publishing data to
>> the Semantic Web if they perceive adequate value (demonstrating that
>> value is where we need to be working even harder!).
>>
>>> System level access to a server is
>>> quite a different beast than being allowed to publish HTML on a website
>>> somewhere. I can, and do, publish HTML, or indeed just about any file I
>>> like, but I don't get to insert code. So 6 lines or 600, it makes no
>>> difference.
>>>
>>> But in any case, this is ridiculous. RDF is just XML text, for goodness
>>> sake.  I need to insert lines of code into a server file,  and write PHP
>>> scripts, in order to publish some RDF or HTML?  That is insane. It would
>>> have been insane in the mid-1990s and its even more insane now.
>>
>> No. This is incorrect. This discussion only applies to the
>> 303-redirect/slash URI pattern. You can avoid this completely by using
>> the hash URI pattern as someone mentioned (sorry for not crediting
>> directly, getting hard to navigate this thread).
>
> Yes, of course, and I apologize for overstating the case. Still, the
> slash-URI seems to be much more acceptable to many unsemantic Webbies, who
> are used to thinking of URIs as being stripped of their post-hash content at
> the slightest internet shiver, so don't regard a name including a hash as
> something 'real'; and it is the case about which all the fuss is being made.
> If the published advice was: always use hash URI patterns, I would be happy.
> But the published advice *starts* with 303 redirects and .htaccess file
> modifications.
>
>>
>>> IMO, it is
>>> you (and Tim and the rest of the W3C) who are stuck in the past here.
>>>  Most
>>> Web users do not, and will not, write code. They will be publishing
>>> content
>>> in a cloud somewhere, even further away from the gritty world of scripts
>>> and
>>> lines of code than people - most people - are now. Most actual content
>>> providers are never going to want to even know that PHP scripts exist,
>>> let
>>> alone be obliged to write or copy one.
>>
>> You've over-interpreted my words here. See above.
>
> If so, I apologise. But think of what Im saying as a cry for help. There are
> a lot of people like me, I suspect, who would really like to help with SW
> deployment and are willing to write RDFa content, but are paralyzed by the
> apparent need to become Web-server hackers in order to do so. It just feels
> *wrong*. Your own metaphor is apt:
>
>>
>>> Martin is exactly right: this is a
>>> MAJOR bottleneck to SWeb adoption. Its up to the people in the TAG to
>>> listen
>>> to this fact and do something about it, not to keep issuing useless
>>>  'best
>>> practice' advice that cannot be followed by 99% of the world.
>>
>> I think that's overplaying things. It's like saying "stop issuing best
>> practices for cardiac surgeons because Average Joe can't use those to
>> help improve his cardiac health".
>
> Well, yes, exactly. Im not a cardiac surgeon, and here I am reading this
> stuff that I naively took to be good advice for improving my cardiac health.
> It didn't say: For Surgeons Only on the cover. If the SWeb is going to rely
> on cardiac surgeons rather then average Joes to get all that RDFa written,
> then its never going to happen.
>
>>
>>> 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.
>>
>> The architecture of the Semantic Web is the architecture of Web. And
>> just as in the Web we have varied publishing patterns/workflows
>> (ranging from simple to hard), so we will in the Semantic Web.
>
> But, and this is where this thread started, right now we don't seem to have
> any easy ones at all. All my yelling has been to try to get you guys to take
> this issue as seriously as I think it deserves to be taken.
>
> Best wishes
>
> Pat
>
>>
>> Cheers,
>>
>> Tom.
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email______________________________________________________________________
>

--
Dr Tom Heath
Researcher
Platform Division
Talis Information Ltd
T: 0870 400 5000
W: http://www.talis.com/

[Martin Hepp (UniBW)]

Dear all:
Fyi - I am in contact with Google as for the clarification of what kind of empty div/span elements are considered acceptable in the context of RDFa. It may take a few days to get an official statement. Just so that you know it is being taken care of...

Martin



Mark Birbeck wrote:

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

  

[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Linde, A.E.]

Discussion on this seems to have died down. I’ve tried to follow this thread but do not have enough SW and RDF knowledge to understand all that was said. But I’d like to learn by being able to publish RDF versions of knowledge in a way that is discoverable and usable by others in LOD fashion.

Could someone summarise this thread in a single (unbiased?) post, please? With the main points being: a) what is/are the blocks on LOD via RDF; b) how does RDFa help and what are its own failings; c) what are the recipes for making data discoverable, linkable and usable if i) one has full access to a server; ii) one has only user directory acccess to a server; iii) one does not know or care what a server is.

Many thanks, from me and I’m sure many others, to anyone who can satisfy these requests.

Cheers,
Tony.

--
Tony Linde
Project Manager
Department of Physics & Astronomy
University of Leicester

---

From: "Martin Hepp (UniBW)" <martin.hepp@...>
Reply-To: <martin.hepp@...>
Date: Wed, 1 Jul 2009 16:51:15 +0100
To: Mark Birbeck <mark.birbeck@...>
Cc: <public-lod@...>, semantic-web at W3C <semantic-web@...>
Subject: Re: .htaccess a major bottleneck to Semantic Web adoption / Was:  Re:   RDFa vs RDF/XML and content negotiation

Dear all:
Fyi - I am in contact with Google as for the clarification of what kind of empty div/span elements are considered acceptable in the context of RDFa. It may take a few days to get an official statement. Just so that you know it is being taken care of...

Martin



Mark Birbeck wrote:

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

  

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009

[Danny Ayers]

2009/7/2 Linde, A.E. <ael13@...>:

> Could someone summarise this thread in a single (unbiased?) post, please?

I'll try to answer the questions, even though I've only skimmed the thread...

> a) what is/are the blocks on LOD via RDF

The vast majority of publication tools and supporting services are
geared towards publishing HTML. While a key piece of Web architecture
is the the ability to publish multiple representations of a given
resource (e.g. both HTML and RDF/XML format documents with a single
URI through content negotiation), the mechanisms needed to do this are
often unavailable from regular hosting services. Similarly the
redirect handling needed to provide a description of a resource that
cannot appear directly on the Web - things, people etc - is also not
possible.
Typically these would be done through using .htaccess files on Apache.

> b) how does RDFa help and what are its own failings;

RDFa allows the RDF to be published in a HTML document, so content
negotiation isn't needed. You get two representations in one.

Again tool support is a problem, although with RDFa being a new spec
the situation is bound to improve.

GRDDL may also be a useful alternative if the source data is available
in an XML format.

> c) what are the recipes for making data discoverable, linkable and usable

there are recipes at:
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
though perhaps a cheat sheet would be a good idea?

 > if i) one has full access to a server;

this is pretty well documented, e.g. as above

> ii) one has only user directory acccess to a server;

while this may often be the same as i) generally I'd suggest it's a
case-by-case thing, depending on the web server configuration

iii) one does not know or care what a server is.

Depending on the nature of the data, it may be possible to use one of
the semweb-enabled document-first publishing tools (a semantic wiki or
CMS). Alternately a relational DB to RDF mapping tool may help.

But best bet right now though would be to have a word with someone
offering linked data publishing services - Talis or OpenLink, may be
others.

I've no doubt missed a lot of points and alternate approaches, but I
these were top of my own mental heap :)

Cheers,
Danny.

--
http://danny.ayers.name