[rdfweb-dev] Syntactic profiling (FOAF document formats)

Dan Brickley danbri at w3.org
Tue Aug 26 18:51:44 UTC 2003


Hi Julian,

re your 'Atom or RSS 2.0 to FOAF's RSS 1.0' in 
http://rdf.burningbird.net/archives/001562.htm

(...kinda dissapointing to read about it 1st in Shelley's weblog.)

(The RSS situation *really* sucks. I don't think we've done anything to 
deserve a fork. Talk to anyone who was involved. Let's not go there.)

As you know I've been working on http://xmlns.com/foaf/0.1/ and have 
more or less got the per-term documentation sorted, and spent some time
this weekend looking at the general documentation. I need to add a 
section on vocabulary extensions and another on syntactic profiles. It
sounds as if both (and their interaction) are close to your concerns. I
wonder if you have any thoughts on what the FOAF spec might say w.r.t. 
syntactic profiles, since you mention that you've been preparing one.

I'm looking at ways (RELAX-NG schemas, for eg.) for
describing restrictions over FOAF-based document formats which still 
allow each instance to be parsed as RDF using generic RDF tools. For eg
one might define a ListOfNamesML format that, inside the usual RDF +
namespaces wrapper, allowed only <foaf:Person> with a <foaf:name> 
required within each. Would such an approach meet the needs you believe 
you're addressing?

I believe there will prove to be many sub-categories of XML document 
which:

i) use FOAF vocabulary
ii) are directly parsable into RDF graphs as RDF/XML

...but which have different rules, constraints and conventions for 
the detailed content of the document.

For example:

  * a FOAF-annotated RSS 1.0 feed
  * photo metadata (per image, per collection)
  * addressbook interchange 
  * IM "buddy lists"  
  * "classic" FOAF files
  * machine-readable bibliographies
  * organisational chart data 
  * foafcorp files
  * family tree data (per person or aggregates; w/ src attributions)
  * spam whitelist filtering data (hashed mailbox lists)
  * etc.
  
Many such XML documents would also use other XML/RDF namespaces, and 
the extensibility requirements (expected doc format rigidity) would 
also likely vary from case to case. The abstract RDF model and its 
XML syntax are the glue that binds together all of these usage 
scenarios.

We need something in the FOAF spec that acknowledges the 
various and varied needs people have for defining FOAF based *file
formats*. I think this can be done without sacrificing the RDF model or 
its XML syntax, though it isn't clear to me yet whether W3C XML Schema,
RELAX-NG, Schematron or prose is the appropriate technology to 
recommend to folks defining syntactic profiles. Quite likely that'll 
vary anyway, depending on their requirements and other context.

While there are tools (Schemarama-ish stuff like Rosco) that suggest 
ways of defining FOAF profiles in terms of the abstract graph, 
I expect most FOAF-based file formats will use XML-level tools, ie. will
define their expectations in terms of element/attribute tagged data.

So the question for the FOAF spec is: what generalisations can we 
make about FOAF profiles.

I was thinking to add to the spec guidelines such as:

"A FOAF syntax profile defines a particular kind of XML/RDF 
document format that uses FOAF vocabulary. Since there are many 
and varied applications that use descriptions of people, there 
may be many different FOAF syntax profiles. A FOAF syntax profile 
describes the subset of RDF/XML documents corresponding to a 
particular usage practice. A FOAF syntax profile MAY be associated 
with a syntactic schema defining an RDF/XML subset. [...]"

   * FOAF instance formats (profiled or generic) SHOULD use RDF/XML syntax
    (or failing that, other cross-vocab encodings of RDF, ie. 
     alternate RDF-in-XML syntaxes)

   * profiles SHOULD define an RDF class defined that names each 
   subset of XML documents (eg. http://example.com/addressbookml#MyFoafSyntacticProfile)

   * (....detail to be discussed)

...and then work through an example of this, perhaps whitelists as 
that's relatively simple.

Probably the biggest issue is whether some folks are so RDF-averse as 
to not be happy with using RDF/XML syntax, even if they get to 
impose additional DTD-esque restrictions. And if that's the case, 
whether that aversion is primarily w.r.t. details of the W3C RDF/XML 
syntax; in which case, I'd like to know whether *generic* alternate 
syntaxes such as the one I'm investigating for Atom would calm the 
irritation. See http://esw.w3.org/topic/SpotOfDrama for examples of 
Atom feeds cast as RDF but serialized in a markup based on SOAP Encoding 
rather than the normal RDF/XML striped syntax. 

Application-specific XML encodings should really be a last resort, 
since they amount to a fork with other FOAF applications and 
vocabulary extensions that have different priorities and concerns. 
If each of the FOAF-based doc formats I list above were to adopt 
their own proprietary XML tagging conventions, we'd lose interop 
between them. The uses to which FOAF-based markup will be put 
are so varied as to make a one-size-fits-all doc format unlikely. 
The challenge is to find a way of making sure that all our 
differently-sized doc formats share a common approach to model 
and to syntax...

Suggestions welcomed.

cheers,

Dan





More information about the foaf-dev mailing list