[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