• Setting up a service is not trivial. […] the essential software solutions (tools) involved have not reached full maturity yet. […] documentation may be lacking the required depth. […] multiple software components need to be setup to work together  […] which requires appropriate expertise.[…]
• Data modeling can be complex. When publishing data on the web, it is advantageous to use existing, registered ontologies. Unfortunately, these ontologies do not always match the data representation of each individual library […] the definitions of individual properties can vary considerably. […] There is no simple answer to the question which is the right thing to do.[…]
• Open data exchange mentality does not exist everywhere. Even before linked data, libraries have exchanged and aligned their data sets. The results of such projects could be prime information sources for connecting linked data sets. Sadly, not all institutions involved share the open exchange mentality, and shared ownership may make it difficult to publish these results.
• Best practices are seen as rules. Linked open data is based largely on best practices rather than rules. However, this pragmatic aspect is not seen as essential in all areas of the linked data community. Deviations from perceived standards tend to be criticized, which can cause institutions new to the semantic web to doubt their decisions – even if they make sense for the organization in question. Libraries should not be deterred by such feedback and rather see this as a motivation to contribute their own experiences and knowledge to the community. Guidelines and best practices should be carefully considered in the context of each institution’s needs, especially in this early forming phase of the semantic cloud.[…]
• Properly modeled data is very useful. Once the data modeling is completed and the data made available, it can be used by others. A colleague at the Technical University of Braunschweig has shown that with properly modeled data, this can result in very useful applications: within a day, he imported our data into a database, added a web interface and had thus created a searchable access to our data.

Seattle consisted of a number of company visits, but it also included a talk at the SemWeb Meetup in Seattle. I gave a presentation on what happened at W3C the last year which, I think, was was well received. (Although one is never sure about these things.) I had a bunch of discussions and chats after the presentation; it was pleasant, relaxing… I and mainly my colleague from W3C, Eric Prud’hommeaux, had also a long discussion with two developers from Microsoft who are involved in the oData work; that was really interesting because we reached the conclusion of possibly outlining together a possible plan whereby we could write down how to “export” oData into RDF, and publish that, e.g., as W3C note (note that there are already systems doing something like that out there, but I am not knowledgeable enough to judge how complete those solutions are). I think it would be good for the community if this happens. It is important for a general Web of Data to include, well, all the data on the Web…

Semtech… it was big. Bigger than last year (I heard and read a figure of a 30% increase in attendance). This industry is lively indeed! The only problem that it was almost too big; it was the conference of eternal frustration:-( Indeed, there were so many things in parallel that one always had the feeling to have missed something because another, parallel session may have been more interesting! I heard presentations from Facebook, from Google, saw stunning visualizations of RDF graphs, or heard about plans on ontology hosting and management. There was a report on the US and UK governmental data work (this stuff still amazes me, though it is not the first time I hear about it), there was a presentation of BestBuy (alas! I missed that one). There was a separate track on the publication world as a separate “vertical” area (and we also had some great discussions with the people from the New York Times with whom we outlined a possible first step in gathering that community). Lots of hallway conversation with companies and institutions and, of course the social life, chatting with David, and Ian, and the other Ian, and Eric, and the other David, and Christine, and Jeremy, and Jim, and Fabien, and Sandro, and Jenni, and… I should stop and not even try to list everybody because it is simply impossible! I also gave an introductory Semantic Web Tutorial (quite a lot of people in the audience, and I think it went well), we had a panel on the W3C RDB2RDF work and another one on SPARQL 1.1. As a nice little touch, I could announce the publication of the W3C RIF Recommendation as a primeur during the tutorial when as I was talking about RIF (the publication itself happened while I was talking…)

There were, as every year, some “buzz” topics. My impression that the linked open governmental data effort was a buzz and was still new information for many. Facebook’s keynote on the Open Graph Protocol crated another buzz. More generally, RDFa was definitely a buzz (big time!). I.e., as I said, this industry is lively and continue to be exciting.

But there are of course challenges. The way I feel it the biggest challenge is not technical. Yes, of course, there are technical issues, but those will be solved, eventually. The issue is outreach, to get to those new communities who may understand the value of a Web of Data in general but have not enough guidance on how to start doing something. How to publish the data, how to link it to other data, how to consume it, use it, mash it up… How to talk to “C-level” people, how to reach out to them. There are books, of course, but not enough; there are tutorials and guides, of course, but not enough; there are experts around but definitely not enough. As one of our discussion partners put it: if I go to any better bookshop, there are rows of books on, say, XML (good or bad, but they are there). But books on RDF, on Linked Data, on SPARQL, on SKOS, on OWL: only a few here and there (comparatively, that is), and some of them are actually quite old. Let alone the problem of trying to hire experts that could do the job. I really feel that this is the biggest challenge our community faces. I say “community” and not only a single organization like W3C or other; the challenge is too great to be solved by one group only. We have been fighting with this issue for a while now, but it is still a challenge… And a challenge for us all who care about that stuff!

It was a good week!

A few weeks ago I have already blogged about the publication of the RDFa 1.1 drafts. An essential, additional, piece of the RDFa puzzle has now been published (as a First Public Working Draft): the RDFa API. (Note that there is no reference to “1.1” in the title: the API is equally valid for versions 1.0 and 1.1 of RDFa. More about this below.)

Defining an API for RDFa was a slightly complex exercise. Indeed, this API has very different constituencies, ie, possible user communities, and these communities have different needs and background knowledge. On the one hand, you have the (for the lack of a better word) “RDF” community, ie, people who are familiar and comfortable with RDF concepts, and are used to handle triples, triple stores, iterating through triples, etc. Essentially, people who either have already a background in using, say, Jena or RDFLib, or who can grasp these concepts easily due to their background. But, on the other hand, there are also people coming more from the traditional Web Application programmers’ community who may not be that familiar with RDF, and who are looking for an easy way to get to the additional data in the (X)HTML content that RDFa provides. Providing a suitable level of abstraction for both of these communities took quite a while, and this is the reason why the RDFa API FPWD could not be published together with RDFa 1.1.

But we have it now. I will give a few examples below on how this API can be used; look at the draft for more details (there more examples there; the examples in this blog use, actually, some of the examples from the document!). The usual caveat applies: this is a working draft with new releases in the future; comments are more than welcome! (Please, send them to public-rdfa-wg@w3.org, rather than answering to this blog.)

The “non-RDF” user

Let me use the same RDFa example as in the previous blog:

<div prefix="relation: http://vocab.org/relationship/ foaf: http://xmlns.com/foaf/0.1/">
   <p about="http://www.ivan-herman.net/foaf#me"
      rel="relation:spouse" resource="http://www.ivan-herman.net/Eva_Boka"
      property="foaf:name">Ivan Herman</p>
</div>

Encoding the (RDF) triples:

<http://www.ivan-herman.net/foaf#me> <http://vocab.org/relationship/spouse> <http://www.ivan-herman.net/Eva_Boka> .
<http://www.ivan-herman.net/foaf#me> <http://xmlns.com/foaf/0.1/name> "Ivan Herman" .

So how can one get to these using the API? The simplest approach is to get the collection of property-value pairs assigned to a specific subject. Using the API, one can say:

>> var ivan = document.getItemBySubject("http://www.ivan-herman.net/foaf#me")

yielding an instance of what the document calls a ”Property Group”. This object contains all the property-value pairs (well, in RDF terms, the predicate-object pairs) that are associated with http://www.ivan-herman.net/foaf#me. It is then possible to find out what properties are defined for a subject:

>> print(ivan.properties)
<http://vocab.org/relationship/spouse>
<http://xmlns.com/foaf/0.1/name>

It is also possible relate back to the DOM node that holds the subject via ivan.origin, and use the get method to get to the values of a specific property, ie:

>>>print(ivan.get("http://xmlns.com/foaf/0.1/name"))
Ivan Herman

Note that, on the level, the user does not really have to understand the details of RDF, of predicates, etc; what one gets back is, essentially, a literal or a representation of an IRI, and that is about it. Simple, isn’t it?

Of course, there is slightly more to it. First of all, finding the property groups only through the subjects may be too restrictive. The API therefore includes similar methods to search through the content via properties (“return all the property groups whose subject has a specific property”) or via type (i.e., rdf:type in RDF terms, @typeof in RDFa terms). One can also search for DOM Nodes rather than for Property Groups. Eg, using

>> document.getElementsByType("http://http://xmlns.com/foaf/0.1/Person")

one can get hold of the elements that are used for persons (e.g., to highlight these nodes or their corresponding subtrees on the screen by manipulating their CSS style). I also used full URI-s everywhere in the examples; it is also possible to set CURIE like prefixes to make the coding a bit simpler and less error prone.

An that is really it for simple applications. Note that many RDFa content (eg, Facebook‘s Open Graph protocol, or Google‘s snippets) include only a few simple statements whose management is perfectly possible with these few methods.

The RDF user

Of course, RDF users may want more and, sometimes, the complexity of the RDF content does require more complex methods. The RDFa API spec does indeed provide a more complex set of possibilities.

The underlying infrastructure for the API is based on the abstract concept of a store. One can create such a store, or can get hold of the default one via:

>> var store = document.data.store

The default store contains the triples that are retrieved from the current page. It is then possible to iterate through the triples, possibly via an extra, user-specified filter. Furthermore, it is possible to  create (RDF) new triples and add them to the store. One can add converter methods that control how typed literals are mapped onto, say, Javascript objects (although an implementation will provide a default set for you). In some ways, fairly standard RDF programming stuff, yielding, for example, to the following code:

>> triples = document.data.store.filter(); // get all the triples
>> for( var i=0; i < triples.size; i++ ) {
>>   print(triples[i]);
>> }
<http://www.ivan-herman.net/foaf#me> <http://vocab.org/relationship/spouse> <http://www.ivan-herman.net/Eva_Boka>
<http://www.ivan-herman.net/foaf#me> <http://xmlns.com/foaf/0.1/name> "Ivan Herman"

There is one aspect that is very well worth emphasizing. The parser to the store is conceptually separated from the store (similarly to, say, RDFLib). What this means is that, though an implementation provides a default parser for the document, it is perfectly possible to add another parser parsing the same document and putting the triples into the same store. The RDFa API document does not require that the parser must be RDFa 1.1; one can create a separate store and use, for example, an RDFa 1.0 parser. But much more interesting is the fact that one can also add a, say, hCard microformat parser that produces RDF triples. The triples may be added to the same store, essentially merging the underlying RDF graphs. Eg, one can have the following:

>> store = document.data.store; // by default, this store has all the RDFa 1.1 content
>> document.data.createParser("hCard",store).parse();

merging the RDFa and the hCard terms in one triple store. I think the possibility to use the RDFa API to, at last, merge the different RDF interpretable syntaxes in this area in one place is very powerful. (It must be noted that the details of the parser interface is still changing; e.g., it is not yet clear how various parsers should be identified. This is for one of the next releases…)

As I said, comments are more than welcome, there is still work to do, but the first, extremely important step has been made!

W3C has just published a Proposed Recommendation for the Rule Interchange Format (RIF); this means, in the W3C jargon, that the technical work is done, and the W3C asks its members for a seal of approval to publish it as Recommendation.

Somehow the RIF development was not on the radar screen of the Semantic Web community. There may be many reasons for that, and I think we should just accept this as part of history. The future is much more important; we should indeed realize that RIF is an important piece of the Semantic Web technical architecture and let us do our best to get it embraced widely.

RIF Core is the simplest variant of RIF. It is not very complicated. It is a simple rule language; one can define a series of Horn rules, there are some safety features built in so that the rules can be executed, conceptually, by a forward chaining engine, it has the familiar XSD datatypes with the usual operations, it operates on URI-s, and it has a notion analogous to RDF blank nodes. There is a separate document that describes how RIF (Core) rules operate with RDF data and how the various semantics (RIF, RDF(S), OWL) work together. The details are not really important here, suffices it to say that it, essentially, works like one would expect as a layperson… The RIF syntax is a little bit convoluted for the moment, but there may be work coming up to improve that in form of alternative, more readable syntaxes.

So what can it be used for? At the W3C LOD Camp in Raleigh (held as part of the WWW2010 conference), Sandro Hawke already gave a simple example why RIF should be interesting for LOD applications. Let me add a few further examples that might be of interest.

Remember OWL-RL? The OWL Working Group has defined a subset of OWL that can be handled by rules. The rules themselves were also published by the OWL WG, albeit using an abstract notation. Those rules can be described in RIF Core as well; the RIF group has published this mapping in a separate document. Following those rules a RIF Core engine can handle OWL-RL directly.

Why is that interesting?—you might ask. Well, there has been quite some discussions when defining OWL RL on whether the features included in OWL RL represent the right set for users. Some claimed that there are other OWL features that could be added; others said that, on the contrary, the complexity of OWL RL is already too high and the features should be reduced to make them more palatable to users. In some ways, the usage of RIF Core may make this discussion moot. Indeed, users, or user communities, can define the rules they are interested in RIF by cherry picking the rules described by the RIF WG in the document cited above. They can send those rules to their RIF Core reasoner alongside their data, and get what they want. If that rule set consists only of 2-3 OWL rules, because that is all the application cares about, than all the better, the RIF inference engine will just do its job faster. If the user wants to add OWL features that are not in OWL RL, that may also be doable; the OWL 2 RDF-Based semantics specification is such that, in many cases, the extra rules can be extracted fairly easily from the OWL 2 Full semantics, using the patterns in the RIF/OWL RL document (although I have to emphasize that this does not work in all cases!). Note that this model of “sending” the RIF rule set alongside the RDF data to a reasoner is exactly the way RIF reasoning is being defined for SPARQL1.1 in the separate Entailment Regimes document (still in draft). Note also that I referred to OWL RL here, but the same approach could be used with RDFS with, obviously, a smaller RIF Rule set.

Another, albeit related application of RIF came to my mind reading an email discussion on whether inferences should be materialized for large LOD datasets or not and, if yes, which ones. As an answer to Vasiliy Faronov’s question, Leigh Dodds also proposed a text to be added to his Linked Data Patterns book. The resulting discussion thread was really about which inferences should really be materialized. Materializing them all may not be realistic; but if only a selection of the possible inferences is used (eg, subset of RDFS or OWL) how would consumers of the data know? It looks like RIF may come to rescue. Publishers could simply publish the rules they use for materializing their inferences in RIF. (Again, this is not always possible; RIF cannot cover the whole of OWL. But it does cover a very large percentage of the use cases.) Consumers may actually choose whether they want to download all the triples, including the inferenced triples, or whether they choose to download data from the “core” dataset only together with the RIF file, and materialize the inferences locally using a local RIF engine (or use the RIF file with an RIF Entailment aware SPARQL 1.1 engine).

RIF is and should be considered as integral and essential part of the Semantic Web Technology landscape. Let us hope many implementations of, at least, RIF Core will bloom to make this a reality! (There is a public list of existing implementations so far.)

So, what are the new things?

1. Separation of RDFa 1.1 Core and RDFa 1.1 XHTML. This is one of the differences visible immediately: instead of one specification (which was the case for RDFa 1.0) we have now two. This comes from the fact that the RDFa attributes may be, and have already been, used in XML languages other than XHTML (SVG or ODF are good examples). Separation of the Core and the XHTML specific features is just a to make such adaptations cleaner. (I will use XHTML examples in this blog, though.)

2. Default term URI (a.k.a. @vocab attribute). RDFa 1.0 has a number of terms that can be used with attributes like @rel or @rev without any further qualifications. Examples are ‘next’ or ‘license’. These values were “inherited” by RDFa 1.0 from HTML; the spec simply assigned a URI for each of those to use them as RDF properties (eg, http://www.w3.org/1999/xhtml/vocab#next or http://www.w3.org/1999/xhtml/vocab#license).

However, a more flexible way of defining such terms, ie, not sticking to a fixed set and URI-s, is very useful for HTML authors in general. That is achieved by the new @vocab attribute: it defines a ‘default term URI’ that is concatenated with any term to form a URI. The mechanism can be applied to most of the RDFa attributes, not only to @rel and @rev. For example, the following RDFa 1.1 code:

<div vocab="http://xmlns.com/foaf/0.1/">
   <p about="#me" typeof="Person" property="name">Ivan Herman</p>
</div>

will generate the familiar FOAF triples:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<#me> a foaf:Person;
      foaf:name "Ivan Herman" .

The effect of @vocab is of course valid for the whole subtree starting at <div> (unless another @vocab takes it over somewhere down the line). This makes simple annotations with RDFa very easy for authors who do not want to deal with the intricacies of URI-s and CURIE-s.

3. Profile documents for terms. The problem with the @vocab mechanism is that it works only with one vocabulary. However, in many cases, one want to mix vocabularies: after all, this is one of the main advantages of using RDF (and hence RDFa). Eg, one would like to encode something like:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rel: <http://vocab.org/relationship/> .
<#me> a foaf:Person;
      foaf:name "Ivan Herman" ;
      rel:spouseOf <http://www.ivan-herman.net/Eva_Boka> .

A solution is to use a profile document. This is a simple RDF document that can be made available in various serializations (though only RFDa is mandatory for an RDFa processor) and describes the mapping of terms to URIs. Eg, one could define the http://example.org/simple-profile.ttl file (using here Turtle syntax for simplicity):

@prefix rdfa: <http://www.w3.org/ns/rdfa#> .
[] rdfa:uri "http://vocab.org/relationship/spouseOf";
  rdfa:term "spouse" .
[] rdfa:uri "http://xmlns.com/foaf/0.1/name";
  rdfa:term "name" .
[] rdfa:uri "http://xmlns.com/foaf/0.1/Person";
  rdfa:term "Person" .

and use that document in an RDFa file as follows:

<div profile="http://example.org/simple-profile.ttl">
   <p about="#me" typeof="Person"
      rel="spouse" resource="http://www.ivan-herman.net/Eva_Boka"
      property="name">Ivan Herman</p>
</div>

yielding the triples we wanted. Note that the @profile attribute allows for several URIs, ie, for several profile documents, and the corresponding term definitions are merged. Here again, a @profile attribute down the tree will supersede term definitions.

Of course, using the profile document is a heavier mechanism and requires, at least conceptually, an extra HTTP request. I am sure there will be community comments on that. However, I personally do not expect average authors to fiddle around much with those profile files. Instead, vocabulary publishers like Google, Yahoo, Facebook, Dublin Core, or Creative Commons may publish the terms they use and understand in the form of such profile documents, and authors could simply refer to those. RDFa tools could (and are encouraged to) cache the information stored in those widely used profile documents which alleviates the HTTP request issue in practice.

4. Profile documents for prefixes. Using profile documents for terms is great but it does not scale very well. If the vocabularies are large then publishers of those vocabularies would have to create and maintain fairly large files. In such cases the CURIE mechanism, already defined in RDFa 1.0, becomes a good alternative: instead of having a separate URI defined explicitly for each term, one can use an abbreviations for the “base” URIs of those vocabularies via prefixes.

In RDFa 1.0 this required an author to add a series of ‘xmlns:XXX’ attributes to the RDFa content. That mechanism is still valid in RDFa 1.1, but one can also define prefixes as part of a profile document. Eg, the previous turtle fragment could have been written as

@prefix rdfa: <http://www.w3.org/ns/rdfa#> .
[] rdfa:uri "http://vocab.org/relationship/";
  rdfa:prefix "relation" .
[] rdfa:uri "http://xmlns.com/foaf/0.1/";
  rdfa:prefix "foaf" .

and the RDFa fragment would then look like:

<div profile="http://example.org/simple-profile.ttl">
   <p about="#me" typeof="foaf:Person"
      rel="relation:spouse" resource="http://www.ivan-herman.net/Eva_Boka"
      property="foaf:name">Ivan Herman</p>
</div>

to generate the same triples as before. This mechanism may become important, as I said, when several large vocabularies (or simply a large number of vocabularies) are used.

5. Usage of @prefix to define CURIE prefixes. Actually, the usage of the xmlns:XXX syntax to set CURIE prefixes was (and is) controversial; there may be host languages that do not work with such attributes. RDFa 1.1 provides therefore an alternative which, though semantically identical, avoids the usage of a ‘:’ character in the attribute name. Using this @prefix attribute an alternative to the previous RDFa could be:

<div prefix="relation: http://vocab.org/relationship/ foaf: http://xmlns.com/foaf/0.1/">
   <p about="#me" typeof="foaf:Person"
      rel="relation:spouse" resource="http://www.ivan-herman.net/Eva_Boka"
      property="foaf:name">Ivan Herman</p>
</div>

which looks very much like an RDFa 1.0 document but using the @prefix attributes instead of @xmlns:foaf and @xmlns:relation. The old @xmlns: approach remains valid, of course, but the new one is preferred from now on.

6. URIs everywhere. The final item I mention is the possibility to use URI-s everywhere, ie, to bypass the CURIE abbreviation mechanism if so desired. Whereas some of the RDFa 1.0 attributes required the usage of CURIE-s (eg, @rel or @property), this is no longer true in RDFa 1.1. The rules are fairly simple: if an attribute value is of the form ‘pp:xxx’ and the ‘pp’ string cannot be interpreted as a CURIE prefix then the string ‘pp:xxx’ is considered to be a URI and is treated as such in the generated RDF. That also means that CURIE-s can be used in @about and @resource without the slightly awkward ‘safe’ CURIE-s.

The development of RDFa 1.1 is obviously not done yet; lots of details are to be checked, and some additional minor features (eg, possible changes on the handling of XML Literals) are still to be worked out. And, first and foremost, community comments on the directions taken are important. But these First Public Working Drafts give the general direction…

AR is of course not a new discipline; I guess the R&D in AR goes back at least 15 years. But the appearance of high-end mobile devices made this, suddenly, a viable business: the fact that the devices have location capabilities and as well as compasses make it possible to create really cool applications. Johannes la Poutré made a nice and short overview of what is happening in this area; another nice example is the “Berlin Wall is back” application.

What does this have to do with Linked Data, you might ask. Well the very essence of these applications is to use data to increase the visual experience of a mobile phone camera. And use lots of data. And use lots of up-to-date and semantically organized data, because applications have to have intelligent filtering to save bandwidth. This means that developers in AR look at linked data with lots of interest; they were pleased to hear about, eg, Dutch governmental data becoming (gradually…) available as linked data, about the LOD cloud, about technologies like Zemanta, Open Calais, RDFa… Yes, AR on mobile might become a significant application area for Linked Data. A space to watch!

(B.t.w., although it was not an augmented reality project, some of you might remember Christian Becker‘s and Chris Bizer‘s work on DBpedia Mobile: that was some sort of a precursor for some of the ideas that appear today as part of AR applications. Just imagine those Wikipedia/DBPedia data appearing on top of what you see with your camera!)

P.S. Putting my W3C hat on: W3C organizes a Workshop on Augmented Reality and Virtual Interactivity, to be held in June, in Barcelona. Interested?

<http://twitter.com/Eyalsela/statuses/10981280232> a <sioc:Post> ;
     dcterms:created "2010-03-24T14:23:06+00:00" ;
     sioc:content "At our second meetup: Mobile applications and websites development
        #w3cdf #W3C [English:http://j.mp/bS8qLU Hebrew: http://j.mp/a3i8Tv"@en ;
     sioc:has_creator <http://semantictweet.com/Eyalsela#me> ;
     sioc:has_topic <http://search.twitter.com/search?q=%23W3C>,  ;
     sioc:links_to <http://j.mp/a3i8Tv> . 

<http://twitter.com/JimThijssen/statuses/10979370533> a <sioc:Post> ;
     dcterms:created "2010-03-24T13:40:04+00:00" ;
     sioc:content "Yeahh #www.stagematcher.nl is volledig #html #w3c #certified B-)"@en ;
     sioc:has_creator <http://semantictweet.com/JimThijssen#me> ;
     sioc:has_topic &t;http://search.twitter.com/search?q=%23certified>,
       <http://search.twitter.com/search?q=%23html>,
       <http://search.twitter.com/search?q=%23w3c> .
...

The RDF content also be directed used, eg, in a SPARQL call, but the combined URI-s of the distiller service and the original data; ugly URI, but can be minted programatically fairly easily. This is cool…

So what is this “Semantic 3D”? What does it have to do with Semantic Web?

Here is a a crash course on 3D graphics: when systems display those beautiful graphics 3D objects that we are all used to, the underlying system transforms complex mathematical descriptions of shapes, surfaces, or 3D bodies into a load of (triangular) meshes that are displayed by the graphics hardware. The mathematical descriptions are purely geometrical and define, say, spline surfaces, planes, or some geometric transformations that place those surface description into space.

These 3D objects represent, usually, some real object. A chair, a car, a tree, or a house. The representation of a chair is a combination of several such shapes; some of those describe the arms, the back, etc. But this information, i.e., that this and this combination of shapes is actually the arm of a chair, is usually lost somewhere in the process. Modelers start with a concept, a “semantic”, and end up with shapes; information is gone on the way. This means that many things cannot be done well: one would like to have semantics based search (“searching for the arm of a chair”), one would like to know the origin of a a particular shape (i.e., how was it created, under what process and transformation), one would like to follow the evolution in time of a particular shape to retrace the designer’s actions, etc., etc. And, due to the huge number of shapes, managing this type (meta) data is far from obvious. Keeping that information in a manageable way together with the geometric processing: we get Semantic 3D.

There was, of course, a slight confusion of terms for me: this notion of semantics would be considered as (meta)data for Semantic Web people. That being said, such data requires controlled vocabularies, and very complicated ones at that, so there are strong connections nevertheless. But there is also semantics in terms of knowledge representation: There are relationships among, and classification of, shape elements, these relationships can represent constraints and other features that can be used for reasoning, for inference. So more complex ontologies come into the picture (and OWL is widely used in this space). These ontologies are often application dependent, reflecting the diversity of application areas from CAD to gaming, or from cultural heritage systems to medical and biological applications. In future, such ontologies should also incorporate features like uncertainty (reflecting the fact that, at least in some areas like protein modeling, those relationships are not necessarily crisp); they should also include features such as provenance or time relationships.

Last but not least: there are lots of data there. I mean lots, stored in biological databases, shape libraries, scanned historical artifacts, each representing an object (like the reproduction of the Ramses statue on the figure) with many many shapes. Integration of that data is a challenge even within one application area, let alone with data at large. It will take a long time when this data will be organized in a way that it could be, say, exposed and integrated as Linked Open Data. But we may get there, eventually (and your truly has done his best to convince the community of the value of doing that…). Standard representations have to be developed, algorithms crystallized, vocabularies and ontologies defined, etc. The good news is that there is a community that is determined to continue working in this direction. The workshop organizers plan to write down a research roadmap (to be put on line within 1-2 weeks), and a special issue of the journal “Computer & Graphics” has been announced, co-edited by Bianca Falcidieno, from the CNR in Genova, and myself. So… stay tuned.

First of all, as one of the comments by Daniel Grace to my previous note made me understand, I could have used the installation DVD I got with my machine to install Xcode, instead of getting on the Web for that. My impression was that this DVD is there only when one has to re-install Snow Leopard, hence I did not really consider this. My bad, I could have saved some transfer time…

So here are some other smallish tricks and discoveries

• You can recycle a bunch of hardware goodies that you might have had for your PC:
  • My mouse works out of the box and, in contrary to the popular belief, the right click also works automatically. Nothing to do…
  • I also have a cheap Logitech USB keyboard: just plugged it in and it worked. The ‘Windows’ key (the one with the Windows Logo, ironically) maps to the most typical Mac key, the one with this curved symbol and usually referred to as ‘Cmd’; the ‘Alt’ and the ‘Ctrl’ are simply reused.
  • Actually… the default keyboard setup, though works, is not ideal. There are indeed some unfortunate small differences in the physical layouts (I use a US keyboard): the horizontal order of the ‘Cmd’ and ‘Alt’ keys are reversed compared to the laptop‘s own keyboard and the ‘~’ character and the ‘±’ characters are also switched. Disagreeable, because one‘s fingers get messed up. But the flexibility of the Mac comes at your rescue for the command keys. Indeed: go to the Keyboard setup in the system preferences, click on the “modifier keys”, be careful to choose the right keyboard on the top menu, and change the setting. I switched the command and option keys and, voilà! it is exactly like on the laptop.
  • I also switched the default setup for the laptop’s keyboard so that the function keys would behave, by default, like the external keyboard’s function key (instead of the built-in facilities like dimming the screen). This helps my fingers remembering the right usage… If you begin to use things like Exposé (most of us have already seen Mac users displaying a small version of all windows on the screen to switch quickly among them, that is the one!) it is good to have the same keyboard setup than on your external keyboard. You can do that change in the ‘Keyboard’ setup panel, too.
  • I also have a small Polycom® Communicator C100 that I use for Skype: although the Polycom site claims that it is usable with Windows only, that is actually not true. I plugged it in and it works. The only thing you cannot do is to start up Skype using the button on the device. Big deal.
  • One difference, though, that cannot really be handled: the PC-s, usually, have two slots for headphones, ie, one for listening and one for the microphone. If you want to use a headphone on the Mac for Skype, for example, you will have to invest into a separate headphone with USB. Which is unfortunate because the Mac laptop has only two USB slots, which is not much these days. That being said, the mike of the laptop itself may be good enough, in which case any headphone will do for listening.
• I need accented characters, plus some other special characters like quote marks or ellipses. Most West-European characters (e.g., for French or German) are available using a two-key solution. For example, to type the character ‘ü’, you have to type ‘Alt-u’ then ‘u’. You also have a help tool: go to the Language & Text setting and choose the ”Keyboard & Character Viewer”. You should also click the ”Show input menu in menu bar”. You will get a symbol on the upper right hand corner of the screen and you can then get a virtual keyboard on your screen which shows what you have to type. The rest is just trying and getting used to. B.t.w., you can also add other keyboard types; e.g., I checked the Hungarian keyboard, too. What happens is that using the same menu item you can change the keyboard to be Hungarian. Although the physical keyboard remains the same, using the virtual keyboard you can get characters like ‘ű’ or ‘ő’. A bit convoluted (better use a real Hungarian keyboard for this case) but can be helpful in some cases.
• The Mac user interface, e.g., the Finder, is the land of keyboard shortcuts. It will take many weeks before I get used to all of them. If you do have David Pogue‘s book, keep the relevant appendix under your pillow. The possibilities in getting around in the Finder are rich and well worth getting used to.
• One of the tiny goodies: if you want to have your shell windows’ title to show the directory you are in, add this to your profile (I use bash, so it is in ‘.bash_profile’:

  PROMPT_COMMAND='echo -ne "\033]0;${PWD/#$HOME/~}\007"'

  A bit cryptic, but it works… (thanks to Carine and Coralie).

• As Karl said in his comment, some GNU software, that are usually installed on a Linux box or with cygwin (e.g., wget) does not come installed. But downloading the source code from the GNU site, going through the configure+makefile dance seems to work. I tried it with wget, although I had to run the configure script with –prefix=$HOME (ie, install the program in my home directory, not into /usr/local). I presume that this is related to the super user vs. administrator account that I noted in my earlier blog.
• Of course, there are programs that crash or have otherwise strange behavior although, truth must be said, until now I had only problems with Thunderbird (in combination with some extensions) and with Komodo Editor, i.e., not with Mac software (I know, this will come:-). It is therefore good to know about the “Force Quit” menu entry under the Apple menu (upper left hand corner). It gives you an easy way to shoot a program.
• OpenOffice (or its Apple equivalent, NeoOffice) is fairly easy to find and well documented. I had more difficulties finding LaTeX, but I found, after all MacTeX. It is a fairly standard (though large) Mac distribution and it seems to work (add /usr/texbin to your Path variable if you want to use it from bash).
• Bluetooth is always black magic. I paired the Mac with my Nokia and (with the extra driver I had to install, see my previous blog) it synchronizes and I can also browse the content of the phone (submenu for the small bluetooth sign on the upper right hand corner), send files to and from. Great. But I also paired it with my EEE PC (runing Linux); I can send files to the EEE PC but not from. No idea why (this worked without problems on Windows).