Re: Additional Examples for RDF/A Primer

* Mark Birbeck <mark.birbeck@x-port.net> [2006-01-13 00:30-0000]
> 
> Hi Dan,
> 
> I'm sure your email arrived before I'd even finished pressing send! ;)
> 
> > > We are in the process of adding some more examples to the RDF/A 
> > > primer. [...]
> > 
> > Sounds fun, I look forward to seeing it.
> 
> I don't know if I did something wrong, but although I attached the draft,
> and can see that it is simply inline text on the end of your reply email.
> Was that me, you or the mailing-list?

I'd like to blame others, but basically the truth is that I can't work
computers (specifically, I'm using Mutt again and am out of touch with
it's UI). Sorry about that, draft arrived fine.


> > > The goal of these additional examples is to provide a very basic 
> > > introduction for new users, and so help someone who might know a 
> > > little HTML to create something like their own FoaF page. However, 
> > > some tricky things do emerge when trying to use FoaF to represent 
> > > contact information at a simple level.
> > 
> > If there are any tweaks we can make to FOAF that improve this 
> > situation, ... it's not set in stone.
> 
> What I'm thinking is that FoaF has some great things in but they bring with
> it the RDF baggage. (No offence, but you know what I mean....) 

I know what you mean. This taskforce is all about lightening the load of 
that baggage, imho.


								When I was
> working through the examples I found that for very basic stuff I just wanted
> to say, here's a phone number and here's an email address. So for _some_ use
> cases, it seemed that using FoaF as a fairly flat vocabulary was useful.


> > > The most difficult issue is that FoaF does not allow a 
> > person to be a 
> > > document
> > 
> > Heh, you just got me thinking about tattoos.
> 
> He he! It's lucky we have guys like you around to think off the edge of the
> paper and back round the other side.


Not being derailed by the cute corner cases is the important bit :)
 
> > Parts of people 
> > might be documents, I'd suggest. But people themselves, 
> > aren't documents. It isn't that FOAF itself disallows people 
> > being documents; that's something the external universe aka 
> > reality enforces. FOAF merely reflects that aspect of reality 
> > into it's little cartoon model of life.
> > FOAF doesn't let you describe something as being both a 
> > person and a document, without being flagged as making a 
> > contradictory claim.
> 
> Yes, I accept that, and wouldn't like to be responsible for creating a false
> reality. ;)

:)

> But my way out of this is to have lots of terms in the entry level part of
> FoaF that can be used without implying 'personhood'. Hence 'something has a
> phone number of abc' is all you can glean from this page, until you know
> more. But since we as humans fill in the gaps, that's plenty to get some
> useful things done (and for our entry level).

you mean like the way we have workplaceHomepage rather than the two-step
workplace; homepage design that might seem a more 'pure' model? 

Actually, 'implying personhood' isn't the problem, is it? If the domain 
of these properties are foaf:Person, I guess that's a useful thing... 
since it means we don't need to state "...and it is of type foaf:Person"
each time in the RDF/A instance data.


> 
> > 	..which is understandable, but raises the entry level 
> > to RDF/A for
> > > a new user just that bit too high. (I'm making the 
> > assumption that the 
> > > first use that most non-RDF people would have for this 
> > would be to tag 
> > > up their blog, yet currently to use FoaF they would have to 
> > create an 
> > > anonymous node to make the distinction between the 
> > foaf:Person and a 
> > > foaf:Document.)
> > 
> > The Person node needn't be anonymous/blank (although many do 
> > follow that style). It just needs to be distinct from the document. 
> 
> Yes, so you end up creating an element with an @about on it, to make that
> distinction, but unfortunately it's not something that would be immediately
> obvious to people as to why.

Yup


> > > For now I have got round this by not actually putting information 
> > > about a home-page into the FoaF file. This means that a 'realistic' 
> > > first document for a new RDF/A user can be something as 
> > simple as this 
> > > (this is from the attached document):
> > > 
> > >   <html xmlns:foaf="http://xmlns.com/foaf/0.1/">
> > >     <head>
> > >       <title>Jo Lamda's Home Page</title>
> > >     </head>
> > >     <body>
> > >       <p>
> > >         Hello. This is <span property="foaf:name">Jo Lamda</span>'s
> > >         home page.
> > 
> > What thing has the foaf:name property here? A Person or a doc part?
> 
> Well, taken in isolation, the thing identified by the URI of the document.

Ahhh, hmmm, etc.

Ok, in that case, an OWL processor that believes the FOAF spec in
RDF/OWL at http://xmlns.com/foaf/0.1/index.rdf should conclude that this
RDF/A expresses a contradiction, just as soon as it hits a property
with a domain of some class disjoint with foaf:Document. If we encourage
people to freely add Person-describing properties here, that's bound 
to happen eventually, even if foaf:name has a more liberal domain.

> At this stage it has no type, since according to FoaF, *anything* can have a
> foaf:name. I did this on purpose, to get the elusive low entry level. If you
> want to use foaf:surname, and whatever applies to foaf:Person you would need
> to create this 'distinct node' that you're referring to. I don't have a
> problem with introducing more advanced concepts like that, at some point,
> provided we have already given people a very easy way in.

The RDF/A syntax tells us that this is the name of the RDF/A document;
but intuition tells us, what we're really talking about is some person.
I hate to say it, but this is an idiom that might work better in GRDDL, 
since the XSLT can be the place where the indirection is hidden, rather
than instance syntax. 

> 
> > I can see the trickyness if we want to make explicit that 
> > we're really talking about a person, not a part of a 
> > document. We'll get the same issue if we're marking up job 
> > adverts, ebay-style listings etc too, of course --- this 
> > isn't a particularly FOAF-related problem.
> 
> Of course, although what I'm playing around with is combination of a low
> 'entry level' for a new RDF/A person, with the 'knowledge' that a specific
> application might have. So if I tell eBay to go retrieve a listing from my
> home-page and give it a URL, even if my home-page doesn't contain
> rdf:type="ebay:listing", but it does contain the title "Dell laptop" and a
> tagged up price, the system could make use of the data.

But it's the price of a laptop described by the HTML page, not the price
of the page? If money is changing hands, people will want to be very
clear about these distinctions.


> Obviously, if you then go on to create these 'distinct nodes' then you could
> have FoaF, eBay listings and so on, all on the same page. Your blog then
> becomes a very easy mechanism for maintaining all sorts of stuff, but that
> would be the 'next level' for our potential authors.

I'd hope so...

> > >         <h2>Work</h2>
> > >         If you want to contact me at work, you can
> > >         either <a rel="foaf:mbox" 
> > href="mailto:jo.lambda@example.org">email
> > >         me</a>, or call <span property="foaf:phone">+1 777 
> > 888 9999</span>.
> > 
> > can we make the phone number be a URI/hyperlink? tel: URI, or 
> > whatever?
> 
> I planned to do that in a later step, since I was trying to start with what
> someone with not a lot of HTML knowledge might do. (I'll also look out some
> Skype, etc., links too, to make it a bit more up-to-date.)


I think Skype use callto:, though not particularly cleanly. Sorry that
might be FUD; will investigate...


> > 
> > 
> > >       </p>
> > >     </body>
> > >   </html>
> > 
> > 
> > I'm still clumsy at reading RDF/A --- is a list of the 
> > equivalent triples, or a graphical representation, available anywhere?
> > 
> > (ah, i see it below... In which case, I realise I'm out of 
> > touch with RDF/A snytax, since I didn't realise it created 
> > those triples from this markup).
> > 
> > > 
> > > (Jo is Joe Lamda's sister...)
> > 
> > I suggest changing her name since the two are 
> > indistinguishable when read aloud, eg. in a teleconference, 
> > or in a talk, or by screen-readers.
> 
> Good idea.
> 
> 
> > > Personally, I think this is acceptable (assuming I've got my syntax 
> > > right), since in this triple-store there is no conflict between the 
> > > URL of the home-page, and the identifier of the object that 
> > owns that 
> > > home-page (which incidentally is *not* a foaf:Person at this point).
> > 
> > Yup. 
> 
> And I was also thinking that if the person who just imported the RDF/A
> wanted to add the fact that this was a person, rather than a company, they
> could do so, since as long as the 'record' is not identified with the same
> URI, everything is sufficiently compartmentalised:
> 
>   [
>     rdf:type foaf:Person;
>     foaf:name "Jo Lamda";
>     foaf:mbox "mailto:jo.lambda@example.org";
>     foaf:phone "+1 777 888 9999";
>     foaf:homepage <http://jo-lamda.blogspot.com/>
>   ] .
> 
> It would mean that the contact management system would need to know where it
> got each set of triples from, so it knew which ones came from outside and
> which were typed in, but I believe that most triple stores would be able to
> handle that.

I'd hope that "rdf:type foaf:Person" need never be typed; it should in 
some way be gettable from the FOAF and RDF/A. Note that SPARQL lets 
you query named graphs, so you could create a named graph for the raw
triples, and another for those generated by doing RDFS/OWL inference
over them alongside the relevant namespace schema docs.


> 
> 
> > The properties used might btw *imply* that the resource is a 
> > foaf:Person, or at least a foaf:Agent... and that little 
> > piece of RDFS/OWL processing could very feasibly be done by 
> > an addressbook reading/parsing/loading the RDF/A.
> 
> Exactly! That was why I was using foaf:name rather than foaf:surname, etc.,
> since that doesn't imply anything.

In the foaf:name case I think this hides the problem that your message
raises, which is that we shouldn't conflate things with pages that 
area about them. 

>
> > > I'm hoping this starts to show how we might make use of all this 
> > > stuff, so any comments gratefully received, particularly on the way 
> > > that FoaF is being used.
> > 
> > I'll try to help...
> 
> Excellent...thanks.
> 
> 
> > Couple practical questions 
> > 
> >  - is there an RDF/A parser ready yet? (XSLT or whatever)
> 
> Jeremy is pretty close, I believe.

Excellent. I believe the W3C XSLT service can now handle XSLT 2 btw
so folk should be able to experiment online, ie. with zero local 
installation. Maybe the RDF Validator could even be patched to 
handle RDF/A, experimentally? (student project, anyone?)

> 
> >  - where's the Primer draft? is it W3C Member-only?
> 
> No, it was posted in a recent email to the list. The HTML is here:
> 
>   <http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-primer>

Thanks / sorry for the confusion earlier.

cheers,

Dan


> Most people seem to be getting better results using the XML version, which
> contains a link to an XSLT stylesheet (so a suitable browser would be
> needed:
> 
>   <http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-primer.xml>
> 
> Thanks for your comments Dan.
> 
> All the best,
> 
> Mark
> 
> 
> Mark Birbeck
> CEO
> x-port.net Ltd.
> 
> e: Mark.Birbeck@x-port.net
> t: +44 (0) 20 7689 9232
> b: http://internet-apps.blogspot.com/
> w: http://www.formsPlayer.com/
> 
> Download our XForms processor from
> http://www.formsPlayer.com/
> 
>

Received on Friday, 13 January 2006 00:59:49 UTC